From: Ingo Molnar <mingo@elte.hu>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-arch@vger.kernel.org, David Miller <davem@davemloft.net>,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: Software prefetching considered harmful
Date: Fri, 20 May 2011 10:34:42 +0200 [thread overview]
Message-ID: <20110520083442.GB22802@elte.hu> (raw)
In-Reply-To: <1305855769.7481.114.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> 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@linux-foundation.org> 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
next prev parent reply other threads:[~2011-05-20 8:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 17:12 Software prefetching considered harmful Linus Torvalds
2011-05-19 19:05 ` Linus Torvalds
2011-05-19 19:28 ` Ingo Molnar
2011-05-21 3:37 ` Michael Cree
2011-05-21 4:18 ` Benjamin Herrenschmidt
2011-05-21 10:42 ` Ingo Molnar
2011-05-19 19:32 ` David Miller
2011-05-19 19:38 ` Linus Torvalds
2011-05-19 19:47 ` David Miller
2011-05-19 23:34 ` Ingo Molnar
2011-05-20 16:01 ` Catalin Marinas
2011-05-20 1:42 ` Benjamin Herrenschmidt
2011-05-20 8:34 ` Ingo Molnar [this message]
2011-05-20 9:13 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110520083442.GB22802@elte.hu \
--to=mingo@elte.hu \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=linux-arch@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).