Re: [PATCH] x86: eliminate redundant/contradicting cache line size config options

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <npiggin@suse.de> wrote:

> The only other use for L1 cache size macro is to pack objects to 
> cachelines better (so they always use the fewest number of lines). But 
> this case is more rare nowadays people don't really count cachelines 
> anymore, but I think even then it makes sense for it to be the largest 
> line size in the system because we don't know how big L1s are, and if 
> you want opimal L1 packing, you likely also want optimal Ln packing.

We could do that - but then this default of X86_INTERNODE_CACHE_SHIFT:

+       default "7" if NUMA

will bite us and turns the 64 bytes L1_CACHE_BYTES into an effective 128 
bytes value.

So ... are you arguing for an increase of the default x86 linesize to 
128 bytes?

If yes then i'm not 100% against it, but we need more data and a careful 
analysis of the bloat effect: a vmlinux comparizon plus an estimation of 
any dynamic bloat effects on this in a representative bootup with an 
enterprise distro config. (SLAB uses the dynamic cacheline size value so 
it's not affected - but there are some other runtime dependencies on 
these kconfig values in the kernel.)

Furthermore, if we do it (double the default line size on x86), then we 
in essence will standardize almost everything on 
X86_INTERNODE_CACHE_SHIFT and CACHE_BYTES loses much of its meaning. If 
we do then we need a vSMP measurement of the effects of this (and an Ack 
from the vSMP folks) - it might work - or it might not.

If that all works out fine (which is a big if) then we can also 
eliminate INTERNODE_CACHE_SHIFT and just have a single 
CACHE_SHIFT/CACHE_BYTES arch tunable.

In any case i will apply Jan's current patch as it certainly is a step 
forward that corrects a few inconsistencies and streamlines the status 
quo. We can then do another patch to change the status quo.

Thanks,

	Ingo