CACHE_LINE_SIZE macro.

[Rodney W. Grimes]

> > 
> > this is a kernel-only interface, so compile time constants are fine there.  What user-land visible interfaces are affected by this setting?  The answer should be 'none'
> > 
> > Warner
> 
> When I commented on Attilio's recent checkins concerning padding of
> locks to cache line size and the fact that the value changes per-cpu and
> we're not well-positioned to handle that right now, his main concern was
> modules matching the kernel.  I had suggested making the padding
> conditional on SMP (because apparently there's no benefit to the padding
> in a UP kernel), but then a module compiled for UP wouldn't work right
> on an SMP kernel, and vice versa.  I'm not sure why that's a problem, my
> solution to that would be "So then don't do that."
> 
> What scares me the most is the mushy definition of what CACHE_LINE_SIZE
> really means.  There's nothing about the name that says "This may not be
> the actual cache line size but it's probably close," but increasingly I
> see people talking about it as if it had such a malleable meaning.  Is
> that consistant with the existing uses in the code?  Is it a good idea?

I agree with your point Ian, one should not be abusing a constant that just
happens to fit the value needs, one should be using a new constant such
as MUTEX_ALIGN.

Interesting things can be found if one runs a find /sys/ -type f | xarges grep ALIGN

Like this pair of contradictions:
./dev/fxp/if_fxpvar.h:#define FXP_FLAG_READ_ALIGN       0x0002  /* align read access with cacheline */
./dev/fxp/if_fxpvar.h:#define FXP_FLAG_WRITE_ALIGN      0x0004  /* end write on cacheline */

Both often wrong, cause the cache line size on most x86 is much larger than 2 or 4 :-)


-- 
Rod Grimes                                                 freebsd at freebsd.org