Re: Update cacheline size on X86_GENERIC

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Saturday 11 October 2008 19:08, Andi Kleen wrote:
> > I guess there is a reasonable argument to not care about P4 so
>
> I don't think it is. Ignoring old systems would be a mistake
> and the wrong signal. One of Linux's forte over the competition
> was always to run reasonable on older systems too.

I think there is a reasonable argument: and that is that most
multiprocessor P4 systems in production and using a GENERIC (ie.
probably not custom but probably vendor compiled) kernel is not
likely to be upgraded to a 2.6.28+ based GENERIC kernel.

I also think there are reasonable arguments the other way, and I
personally also think it might be better to leave it 128 (even
if it is unlikely, introducing a regression is not good).


> There are millions and millions of P4s around.
> And they're not that old, they're still shipping in fact.

Still shipping in anything aside from 1s systems?


> And the point of GENERIC was to be a reasonable default on all
> systems.
>
> If you want to optimize for a specific CPU you're always free
> to compile the kernel for that. But GENERIC should be really
> GENERIC.
>
> > much in today's GENERIC kernel. If it is worth around 1% on tpc
> > on a more modern architecture, that is a pretty big motivation
> > to change it too...
>
> TPC is a extreme case, it is extremly cache bound.

Still, 1% there is a large increase.


> Besides I suspect the TPC issue could be fixed with a minimal
> tweaks without breaking other systems.

That would be nice. It would be interesting to know what is causing
the slowdown.