From: Paul Moore <paul.moore@hp.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
x86@kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
arjan@infradead.org, davem@davemloft.net
Subject: Re: [PATCH] Remove implicit list prefetches for most cases
Date: Wed, 08 Sep 2010 08:32:59 -0400 [thread overview]
Message-ID: <1283949179.4480.3.camel@flek> (raw)
In-Reply-To: <1283936344-19124-1-git-send-email-andi@firstfloor.org>
On Wed, 2010-09-08 at 10:59 +0200, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> We've had explicit list prefetches in list_for_each and friends
> for quite some time. According to Arjan they were originally
> added for K7 where they were a slight win.
>
> It's doubtful they help very much today, especially on newer CPUs with
> aggressive prefetching. Most list_for_eachs bodies are quite short and
> the prefetch does not help if it doesn't happen sufficiently in advance
> or when the data is not really cache cold.
>
> The feedback from CPU designers is that they don't like us using explicit
> prefetches unless there is a very good reason (and list_for_each* alone
> clearly isn't one)
>
> Also the prefetches cause the list walks to generate bad code,
> increase the number of registers needed.
If prefetch() is generally considered a "Bad Thing", I'm OK with just
removing them from NetLabel; no need to rename and conditionalize. I
put them in the netlbl_af[4,6]list_*() routines because those routines
were modeled after the normal list routines which had prefetches and I
just assumed someone much smarter had found them to be a win.
--
paul moore
linux @ hp
next prev parent reply other threads:[~2010-09-08 12:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 8:59 [PATCH] Remove implicit list prefetches for most cases Andi Kleen
2010-09-08 12:32 ` Paul Moore [this message]
2010-09-08 13:45 ` Andi Kleen
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=1283949179.4480.3.camel@flek \
--to=paul.moore@hp.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.