From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, richard.brunner@amd.com
Subject: Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers
Date: Wed, 17 Sep 2003 05:25:51 +0200 [thread overview]
Message-ID: <20030917052551.3abee289.ak@suse.de> (raw)
In-Reply-To: <20030916194446.030d8e70.akpm@osdl.org>
On Tue, 16 Sep 2003 19:44:46 -0700
Andrew Morton <akpm@osdl.org> wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> >
> > This is much more efficient than the previous workaround used in the kernel,
> > which checked for AMD CPUs in every prefetch(). This can be seen
> > in the size of the vmlinux:
>
> That is hardly a serious comparison: the workaround is just to stop the
> oopses while this gets sorted out. It makes no pretense at either
> efficiency or permanence.
It was mainly to show that the patch is a better solution than what currently
is in the kernel.
>
> > Without patch:
> > text data bss dec hex filename
> > 4020232 665956 169092 4855280 4a15f0 vmlinux
> > With patch:
> > 4011578 665973 169092 4846643 49f433
>
> hrm. Why did data grow?
Probably because of the two __get_user in is_prefetch. I suspect their exception
tables get accounted to data.
>
> > With prefetch check: 3.7268 microseconds
> > Without prefetch check: 3.65945 microseconds
>
> We don't know how much of this difference is due to removing the branch and
> how much is due to reenabling prefetch.
None at all. The test did not measure prefetch performance, but just
how much overhead is_prefetch adds to the page fault path.
AFAIK there is no prefetch in the do_page_fault -> fail to find vma -> signal delivery
path.
As for measuring prefetch I'm not sure it makes sense. It depends a lot
on how fast your memory is, how thrashed your caches are, how many
CPUs you have (e.g. on Opteron memory latency varies based on the
number of CPUs) etc. So even if it isn't a win on some system
it can help on others.
> It would be interesting to see comparative benchmarking between prefetch
> and no prefetch at all, see whether this feature is worth its icache
> footprint.
Maybe. But that would be really a separate thing. even with prefetch completely
removed from the kernel we would still need a workaround for user space.
-Andi
next prev parent reply other threads:[~2003-09-17 3:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-17 2:22 [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers Andi Kleen
2003-09-17 2:44 ` Andrew Morton
2003-09-17 3:25 ` Andi Kleen [this message]
2003-09-17 4:53 ` Nick Piggin
2003-09-17 5:08 ` Andrew Morton
2003-09-17 5:19 ` Nick Piggin
2003-09-17 7:15 ` Dave Hansen
2003-09-17 5:26 ` Andi Kleen
2003-09-17 5:44 ` Nick Piggin
2003-09-17 19:53 ` Linus Torvalds
2003-09-17 20:21 ` Andi Kleen
2003-09-17 20:50 ` Linus Torvalds
2003-09-17 21:12 ` Andi Kleen
2003-09-18 15:38 ` Jamie Lokier
2003-09-18 16:04 ` Jamie Lokier
2003-09-18 17:06 ` Andi Kleen
2003-09-18 19:48 ` Jamie Lokier
2003-09-19 6:55 ` Kai Henningsen
2003-09-19 10:02 ` Andreas Schwab
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=20030917052551.3abee289.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.brunner@amd.com \
--cc=torvalds@osdl.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