Re: ZFS committed to the FreeBSD base.

From: Craig Boston <craig_at_xfoil.gank.org>
Date: Thu, 12 Apr 2007 13:51:59 -0500
On Thu, Apr 12, 2007 at 11:06:03AM -0500, Rick C. Petty wrote:
> On Thu, Apr 12, 2007 at 10:54:17AM +0200, Dag-Erling Sm?rgrav wrote:
> > 
> > Our native atomic operations are all defined as either macros or
> > static inline functions in machine/atomic.h, so we can easily make
> > this choice at compile time based on a config option.
> 
> Is there any way we could make the choice at boot time, by checking for
> presence of the CX8 feature?  Either as something like:
> 
> extern int feature_cx8;		/* or MIB variable */
> #define CMPXCHG8(a)	(feature_cx8 ? { _asm "..." } : emulate_cmpxch8(a))

For something this low level my opinion is it's better to stay with
compile time options.  After all, in the above example, cmpxchg8 is a
single machine instruction.  How much overhead does it add to retrieve a
variable from memory and check it, then jump to the correct place?
Enough that it outweighs the benefit of using that instruction in the
first place?

For entire functions that have been optimized (bzero comes to mind) you
can always either use a function pointer or overwrite the code in memory
with the optimized version.  The function call overhead presumably isn't
that much compared to the work that the function is doing.

> Otherwise something like ZFS which utilizes this feature a lot could
> check the MIB variable and set different fn ptr in its device structure,
> or something along those lines.  Of course, that would require compiling
> the same code twice essentially, but it had the advantage that it would
> work on non-CX8 systems and that it would be fast on systems with CX8.

I agree this makes sense for some things, but atomic operations are
supposed to be as fast as possible -- preferably single machine
instructions I can't think of anything short of JIT compiling the kernel
that wouldn't be a high price to pay.

Craig
Received on Thu Apr 12 2007 - 16:52:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:08 UTC