From: Paul Mackerras <paulus@samba.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Rik van Riel <riel@redhat.com>,
Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: A scrub daemon (prezeroing)
Date: Fri, 4 Feb 2005 20:20:44 +1100 [thread overview]
Message-ID: <16899.15980.791820.132469@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0502032220430.28851@schroedinger.engr.sgi.com>
Christoph Lameter writes:
> If the program does not use these cache lines then you have wasted time
> in the page fault handler allocating and handling them. That is what
> prezeroing does for you.
The program is going to access at least one cache line of the new
page. On my G5, it takes _less_ time to clear the whole page and pull
in one cache line from L2 cache to L1 than it does to pull in that
same cache line from memory.
> Yes but its a short burst that only occurs very infrequestly and it takes
It occurs just as often as we clear pages in the page fault handler.
We aren't clearing any fewer pages by prezeroing, we are just clearing
them a bit earlier.
> advantage of all the optimizations that modern memory subsystems have for
> linear accesses. And if hardware exists that can offload that from the cpu
> then the cpu caches are only minimally affected.
I can believe that prezeroing could provide a benefit on some
machines, but I don't think it will provide any on ppc64.
Paul.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-02-04 9:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-21 20:29 Christoph Lameter
2005-01-27 12:15 ` David Woodhouse
2005-01-27 13:12 ` Robin Holt
2005-01-27 13:14 ` David Woodhouse
2005-01-27 17:02 ` Christoph Lameter
2005-02-08 11:31 ` Ralf Baechle
2005-02-02 15:32 ` Marcelo Tosatti
2005-02-02 19:05 ` Christoph Lameter
2005-02-02 16:31 ` Marcelo Tosatti
2005-02-02 21:31 ` Christoph Lameter
2005-02-02 21:39 ` David Woodhouse
2005-02-03 3:06 ` Rik van Riel
2005-02-03 23:39 ` Paul Mackerras
2005-02-04 0:59 ` Christoph Lameter
2005-02-04 5:30 ` Paul Mackerras
2005-02-04 6:26 ` Christoph Lameter
2005-02-04 6:43 ` Nick Piggin
2005-02-04 6:50 ` Christoph Lameter
2005-02-04 9:20 ` Paul Mackerras [this message]
2005-02-04 9:28 ` Andi Kleen
2005-02-04 17:02 ` Christoph Lameter
2005-02-04 22:25 ` Paul Mackerras
2005-02-02 21:00 ` Maciej W. Rozycki
2005-02-02 21:33 ` David Woodhouse
-- strict thread matches above, loose matches on Subject: below --
2005-01-04 23:13 Prezeroing V3 [1/4]: Allow request for zeroed memory Christoph Lameter
2005-01-08 21:12 ` Hugh Dickins
2005-01-08 21:56 ` David S. Miller
2005-01-21 20:15 ` A scrub daemon (prezeroing) Christoph Lameter
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=16899.15980.791820.132469@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=riel@redhat.com \
/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