From: Chris Wedgwood <cw@f00f.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Florian Weimer <fw@deneb.enyo.de>,
7eggert@gmx.de, Christoph Lameter <clameter@sgi.com>,
akpm@osdl.org, linux-ia64@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: Prezeroing V2 [3/4]: Add support for ZEROED and NOT_ZEROED free maps
Date: Sun, 26 Dec 2004 16:01:12 -0800 [thread overview]
Message-ID: <20041227000112.GB29854@taniwha.stupidest.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0412261511030.2353@ppc970.osdl.org>
On Sun, Dec 26, 2004 at 03:12:45PM -0800, Linus Torvalds wrote:
> Anyway, at this point I think the most interesting question is
> whether it actually improves any macro-benchmark behaviour, rather
> than just a page fault latency tester microbenchmark..
i can't see how is many cases it won't make things *worse* in many
cases, especially if you use hardware
it seems you will be evicting (potentially) useful cache-lines from
the CPU when using hardware scrubbing in many cases and when using the
CPU if the tuning isn't right just trashing the caches anyhow
I'd really like to see how it affects something like make -j<n> sorta
things (since gcc performance is something i personally care about
more than how well some contrived benchmark does)
--
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:[~2004-12-27 0:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.n0l29ap.1nqg39@ifi.uio.no>
[not found] ` <fa.n04s9ar.17sg3f@ifi.uio.no>
2004-12-24 21:10 ` Bodo Eggert
2004-12-26 23:02 ` Florian Weimer
2004-12-26 23:12 ` Linus Torvalds
2004-12-26 23:24 ` Florian Weimer
2004-12-27 1:37 ` Ingo Oeser
2004-12-27 4:33 ` Zwane Mwaikambo
2004-12-27 0:01 ` Chris Wedgwood [this message]
2005-01-03 20:30 ` Christoph Lameter
[not found] <B8E391BBE9FE384DAA4C5C003888BE6F02900FBD@scsmsx401.amr.corp.intel.com>
[not found] ` <41C20E3E.3070209@yahoo.com.au>
2004-12-21 19:55 ` Increase page fault rate by prezeroing V1 [0/3]: Overview Christoph Lameter
2004-12-23 19:29 ` Prezeroing V2 [0/3]: Why and When it works Christoph Lameter
2004-12-23 19:33 ` Prezeroing V2 [1/4]: __GFP_ZERO / clear_page() removal Christoph Lameter
2004-12-23 19:34 ` Prezeroing V2 [3/4]: Add support for ZEROED and NOT_ZEROED free maps 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=20041227000112.GB29854@taniwha.stupidest.org \
--to=cw@f00f.org \
--cc=7eggert@gmx.de \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=fw@deneb.enyo.de \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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