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. CraigReceived 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