Re: Is there a way to obtain a machine's cache line size?

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 21 Jan 2011, at 04:00 , Paul Koning wrote:
> On Jan 20, 2011, at 2:47 PM, der Mouse wrote:
> 
>>> I see there is a compile time constant CACHE_LINE_SIZE in
>>> <sys/param.h> which currently seems to be always be set to 64, but
>>> I'm pretty certain that is not necessarily a correct value.
>> 
>> You are correct; to cite the one example I currently have swapped into
>> my brain, the Super-H used in the Dreamcast has 32-byte cache lines
>> (true of the I-cache and D-cache both).
> 
> I'm curious why non-kernel components would care.

    http://en.wikipedia.org/wiki/False_sharing

Data structures shared for writing on multiprocessors already have
miserable cache performance since every time someone else writes the
data structure that cache line gets invalidated out of your cache.  You
make bad worse if you store unrelated stuff on the same cache line since
it then shares the same crappy cache performance for no good reason.  This
is as true for threaded programs running in user space as it is for kernel
software.

If you are running on a multiprocessor you usually want shared-for-writing
structures alone on their cache lines; if you can get an accurate number
for the machine you are on you won't waste memory on worst case assumptions.
You would also like to know if the code is in fact running on a single
processor since, in that case, you are slightly better off not spreading
data across multiple cache lines (if everyone is sharing the same cache
there is no invalidation problem, and spreading stuff across fewer cache
lines means there are fewer cache lines to cache).

The "coherency_unit" variable in the kernel holds an appropriate number
(or it would if architecture-specific code actually set it appropriately,
but I don't see anything which does that right now).  It should be set
to the data cache line size on a multiprocessor, and is set to a small
number on a uniprocessor.

> The question also gets amusing when the cache line size varies among the 
> caches.  That's not all that common, but it certainly happens.

I don't think that's much of an issue in practice.  The number you want
is the cache invalidation size for the cache program data is normally
stored in, and there is generally only one number for that.

Dennis Ferguson