From: Andi Kleen <ak@muc.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Dave Hansen <haveblue@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mel Gorman <mel@csn.ul.ie>,
linux-ia64@vger.kernel.org, Jens.Maurer@gmx.net
Subject: Re: [PATCH] add a clear_pages function to clear pages of higher order
Date: Fri, 18 Mar 2005 19:28:08 +0000 [thread overview]
Message-ID: <20050318192808.GB38053@muc.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0503180652350.15022@schroedinger.engr.sgi.com>
On Fri, Mar 18, 2005 at 07:00:06AM -0800, Christoph Lameter wrote:
> On Fri, 18 Mar 2005, Denis Vlasenko wrote:
>
> > NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> > the fact that zeroed page ends up evicted from cache. Luckily, this is exactly
> > what you want with prezeroing.
>
> These are pretty significant results. Maybe its best to use non-temporal
The differences are actually less. I do not know what Denis benchmarked,
but in my tests the difference was never more than ~10%. He got a zero
too much?
It does not make any sense if you think of it - the memory bus
of the CPU cannot be that much faster than the cache.
And the drawback of eating the cache misses later is really very
significant.
> stores in general for clearing pages? I checked and Itanium has always
> used non-temporal stores. So there will be no benefit for us from this
That is weird. I would actually try to switch to temporal stores, maybe
it will improve some benchmarks.
> approach (we have 16k and 64k page sizes which may make the situation a
> bit different). Try to update the i386 architectures to do the same?
Definitely not.
You can experiment with using it for the cleaner daemon, but even
there I would use some heuristic to make sure you only use it
on a page that are at the end of a pretty long queue.
e.g. if you can guarantee that the page allocator will go through
500k-1MB before going to the NT page that is cache cold it may
be a good idea. But that might be pretty complicated and I am not
sure it will be worth it.
But for the clear running in the page fault handler context it is
definitely a bad idea.
-Andi
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@muc.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Dave Hansen <haveblue@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mel Gorman <mel@csn.ul.ie>,
linux-ia64@vger.kernel.org, Jens.Maurer@gmx.net
Subject: Re: [PATCH] add a clear_pages function to clear pages of higher order
Date: 18 Mar 2005 20:28:08 +0100
Date: Fri, 18 Mar 2005 20:28:08 +0100 [thread overview]
Message-ID: <20050318192808.GB38053@muc.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0503180652350.15022@schroedinger.engr.sgi.com>
On Fri, Mar 18, 2005 at 07:00:06AM -0800, Christoph Lameter wrote:
> On Fri, 18 Mar 2005, Denis Vlasenko wrote:
>
> > NT stores are not about 5% increase. 200%-300%. Provided you are ok with
> > the fact that zeroed page ends up evicted from cache. Luckily, this is exactly
> > what you want with prezeroing.
>
> These are pretty significant results. Maybe its best to use non-temporal
The differences are actually less. I do not know what Denis benchmarked,
but in my tests the difference was never more than ~10%. He got a zero
too much?
It does not make any sense if you think of it - the memory bus
of the CPU cannot be that much faster than the cache.
And the drawback of eating the cache misses later is really very
significant.
> stores in general for clearing pages? I checked and Itanium has always
> used non-temporal stores. So there will be no benefit for us from this
That is weird. I would actually try to switch to temporal stores, maybe
it will improve some benchmarks.
> approach (we have 16k and 64k page sizes which may make the situation a
> bit different). Try to update the i386 architectures to do the same?
Definitely not.
You can experiment with using it for the cleaner daemon, but even
there I would use some heuristic to make sure you only use it
on a page that are at the end of a pretty long queue.
e.g. if you can guarantee that the page allocator will go through
500k-1MB before going to the NT page that is cache cold it may
be a good idea. But that might be pretty complicated and I am not
sure it will be worth it.
But for the clear running in the page fault handler context it is
definitely a bad idea.
-Andi
next prev parent reply other threads:[~2005-03-18 19:28 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-10 20:35 [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-10 21:38 ` Dave Hansen
2005-03-10 22:46 ` Christoph Lameter
2005-03-11 1:03 ` Christoph Lameter
2005-03-11 8:08 ` Denis Vlasenko
2005-03-17 1:33 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-17 1:33 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-18 9:54 ` Denis Vlasenko
2005-03-18 9:54 ` Denis Vlasenko
2005-03-18 15:00 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-18 15:00 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-18 19:28 ` Andi Kleen [this message]
2005-03-18 19:28 ` Andi Kleen
2005-03-18 20:19 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-18 20:19 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-20 0:20 ` Denis Vlasenko
2005-03-21 15:30 ` Denis Vlasenko
2005-03-24 18:34 ` David Mosberger
2005-03-24 18:34 ` David Mosberger
2005-03-24 18:41 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-24 18:41 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-24 19:03 ` [PATCH] add a clear_pages function to clear pages of higher David S. Miller
2005-03-24 19:03 ` [PATCH] add a clear_pages function to clear pages of higher order David S. Miller
2005-03-24 22:49 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-24 22:49 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-24 23:13 ` [PATCH] add a clear_pages function to clear pages of higher David S. Miller
2005-03-24 23:13 ` [PATCH] add a clear_pages function to clear pages of higher order David S. Miller
2005-03-25 2:29 ` [PATCH] add a clear_pages function to clear pages of higher David S. Miller
2005-03-25 2:29 ` [PATCH] add a clear_pages function to clear pages of higher order David S. Miller
2005-03-25 2:43 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-25 2:43 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-03-27 17:12 ` Andi Kleen
2005-03-27 17:12 ` Andi Kleen
2005-03-27 18:23 ` [PATCH] add a clear_pages function to clear pages of higher David S. Miller
2005-03-27 18:23 ` [PATCH] add a clear_pages function to clear pages of higher order David S. Miller
2005-03-29 1:58 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-03-29 1:58 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-04-06 0:15 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-04-06 0:15 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-04-06 0:23 ` [PATCH] add a clear_pages function to clear pages of higher David Mosberger
2005-04-06 0:23 ` [PATCH] add a clear_pages function to clear pages of higher order David Mosberger
2005-04-06 0:33 ` [PATCH] add a clear_pages function to clear pages of higher Christoph Lameter
2005-04-06 0:33 ` [PATCH] add a clear_pages function to clear pages of higher order Christoph Lameter
2005-04-06 4:48 ` [PATCH] add a clear_pages function to clear pages of higher David Mosberger
2005-04-06 4:48 ` [PATCH] add a clear_pages function to clear pages of higher order David Mosberger
2005-04-06 5:15 ` Gerrit Huizenga
2005-04-06 5:15 ` Gerrit Huizenga
2005-04-06 16:03 ` Grant Grundler
2005-04-06 16:03 ` Grant Grundler
2005-03-18 10:12 ` 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=20050318192808.GB38053@muc.de \
--to=ak@muc.de \
--cc=Jens.Maurer@gmx.net \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=haveblue@us.ibm.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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.