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

[Ingo Molnar <mingo@elte.hu>]

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

> On Mon, Nov 23, 2009 at 09:34:59AM +0100, Ingo Molnar wrote:
> > 
> > * Arjan van de Ven <arjan@infradead.org> wrote:
> > 
> > > On Thu, 19 Nov 2009 09:13:07 +0100
> > > Nick Piggin <npiggin@suse.de> wrote:
> > > > 
> > > > My other point was just this, but I don't care too much. But it is
> > > > worded pretty negatively. The key here is that increasing the value
> > > > too large tends to only cost a very small amount of size (and no
> > > > increase in cacheline foot print, only RAM). 
> > > 
> > > 128 has a pretty significant impact on TPC-C benchmarks.....
> > > it was the top issue until mainline fixed it to default to 64
> > 
> > Mind sending a patch that sets the default to 64 on NUMA too?
> 
> This is what I mean. It should all be the same value, and that
> value should depend on the architectures to support (rather than
> NUMA or something like that). With the internode simply being
> the exception for the exceptional vSMP architecture.
> 
>  
> > P4 based NUMA boxes are ... a bad memory to be forgotten.
> 
> I still think it would make sense to do this via Kconfig rather than 
> implicitly saying that we don't care about P4s even if the user has 
> apparently wanted to support them.

That was what i meant. Right now if P4 is set in the .config we'll use a 
cache-shift of 7 - i.e. 128 byte cacheline size.

What we want is to remove that NUMA dependent quirk - it doesnt make 
sense.

	Ingo