CACHE_LINE_SIZE macro.

[Warner Losh]

I think the real answer is to not abuse CACHE_LINE_SIZE for these things at all, but make it a per-arch decision...  That way mips32 could, for example, not align and mips64 could if it wanted to...

Having this be an ABI thing would be unfortunate.

Warner


On Nov 6, 2012, at 2:32 PM, Adrian Chadd wrote:

> On 5 November 2012 04:01, Rodney W. Grimes
> <freebsd at pdx.rh.cn85.chatusa.com> wrote:
> 
>> I did not see -any- data presented that showed how this was proven to be of benifit.
> 
> The intel guys didn't post data, but they did do their investigations.
> 
>> Why not just go out and cache align every data structure in the kernel.... :-)   A benchmark well show an improvement I am sure of that.
>> This may actually be begging for the old technique of carefull handcrafted structs that are such that things LIKE mutexes naturally end up
>> on a proper boundary.   I bet you the boundary is actually 4 byte, independent of cache line size.
> 
> Andre at least has noticed that ordering of things in the text section
> of the kernel (ie, what decisions are made at compile/link time) are
> actually causing measurable performance changes.
> 
> And I think the compiler is naturally aligning these things in
> multiples of 4 bytes.
> 
> The multi-core, multi-system architectures seem to be behaving
> slightly crazier than one expects.. where things like the contention
> is done not based on cache size, but by some larger chunk (256
> bytes?).
> I'm not up to date on this stuff; Juli and Warner would know better than I.
> 
> TL;DR - yes, more data is needed, but please don't discount the impact
> of not cache aligning these shared structures.
> 
> 
> Adrian