CACHE_LINE_SIZE macro.

[Juli Mallett]

On Mon, Nov 5, 2012 at 9:38 AM, Ian Lepore <freebsd at damnhippie.dyndns.org>wrote:

> 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?


Agreed.  If the point of the macro is to ensure that something aligned and
padded to that size will never, ever share a cache line, and if it affects
module builds, it seems like the only really safe thing would be just to
align to page size, and enough of all this more conservative, namely
too-conservative, stuff.  And it shouldn't be named such that anyone tries
to make it even remotely related to anything that may vary within an
architecture.

I had thought there were user/kernel interfaces where it might start to
matter, but if not then the module/kernel interfaces are the worst of it,
but still bad enough.  (Although there are other things complicating things
on MIPS based on CPU type, it would be nice to find ways to reduce those
things, rather than increasing them.)