Messages in this thread | | | From | Nick Piggin <> | Subject | Re: Update cacheline size on X86_GENERIC | Date | Sat, 11 Oct 2008 22:42:27 +1100 |
| |
On Saturday 11 October 2008 22:22, Andi Kleen wrote: > On Sat, Oct 11, 2008 at 07:29:19PM +1100, Nick Piggin wrote: > > 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). > > The issue is also that the regression will be likely large.
Yeah, that is what I'm worried about. If it was a simple case of 1% loss on P4 for 1% gain on Core2, it would be a good change. But it might be huge losses on P4s.
> False sharing can really hurt when it hits as you know, because > the penalties are so large. > > > > 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? > > Remember the first Core2 based 4S (Tigerton) Xeon was only introduced last > year and that market is quite conservative. For 2S it's a bit longer, but > it wouldn't surprise me there if new systems are still shipping. > > Also to be honest I doubt the theory that older systems > are never upgraded to newer OS.
Yeah, fair enough.
> > That would be nice. It would be interesting to know what is causing > > the slowdown. > > At least that test is extremly cache footprint sensitive. A lot of the > cache misses are surprisingly in hd_struct, because it runs > with hundred of disks and each needs hd_struct references in the fast path. > The recent introduction of fine grained per partition statistics > caused a large slowdown. But I don't think kernel workloads > are normally that extremly cache sensitive.
That's interesting. struct device is pretty big. I wonder if fields couldn't be rearranged to minimise the fastpath cacheline footprint? I guess that's already been looked at?
| |