Re: Software prefetching considered harmful

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote:

> On Thu, 2011-05-19 at 12:05 -0700, Linus Torvalds wrote:
> > On Thu, May 19, 2011 at 10:12 AM, Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > Now, notice that right now I'm *only* talking about removing it for
> > > the "hlist" cases (patch attached). I suspect we should do the same
> > > thing for all the list helpers.
> > 
> > Actually, it's the "rcu" versions of the hlist helpers that need this
> > most, since those are the performance-critical ones and the ones used
> > in avc traversal. So the previous patch did nothing.
> > 
> > So here's the actual patch I think I should commit.
> > 
> > Added davem, benh and rmk explicitly - I think you're on linux-arch,
> > but still..  You may have machines that like prefetch more, although I
> > think the "pollute the L1 cache" issue means that even if  you don't
> > have the NULL pointer microtrap issue you'll still find this actually
> > performs better..
> 
> Asked our local performance god:
> 
> Anton Blanchard: yeah we found this 5 years ago, i thought intel were filtering null prefetches
> Anton Blanchard: turns out they werent. funny
> 
> :-)

Yeah, over the past 10 years we have been suffering from an increasing level of 
blindness in the area of x86 performance analysis. Our old tools gradually 
deteriorated, the hardware got smarter and more parallel and it was harder and 
harder to see what happens. The 32-bit/64-bit split did not help us stay 
focused either. I think i warned about this 4-5 years ago at a KS.

This has improved meanwhile, we now have better tools (*wink* :) and have a 
good performance monitoring model (*wink* :) and people are again looking at 
the fine details and i think we now have a good chance to speed up the kernel 
again and keep it fast - and not just on PowerPC which has its envied Olympus 
of performance gods! :-)

Watching out for performance is a fundamentally critical mass thing: for a long 
time it seems a Sisyphean task with little progress, then it just happens very 
quickly.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux