From: Hugh Dickins <hugh@veritas.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Ulrich Drepper <drepper@gmail.com>,
blaisorblade@yahoo.it,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch 2/3] MAP_NOZERO - implement sys_brk2()
Date: Wed, 27 Jun 2007 19:32:47 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0706271921280.29060@blonde.wat.veritas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706271111040.32731@alien.or.mcafeemobile.com>
On Wed, 27 Jun 2007, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Hugh Dickins wrote:
>
> > In honesty, I should add that I dislike and distrust Davide's
> > MAP_NOZERO very much indeed! Would much rather leave my cpus
> > spending a little time in clear_page(). A uid in struct page
> > (though I'm sure we could find somewhere to tuck it away) -
> > the horror, the horror! But I've so far failed to find a killer
> > argument against it, and am hoping for someone else to do so.
>
> Little time? Please, do not trust me. Start oprofile and run a kernel
> build. Look, I'm not even talking about som micro benchmark explicitly
> built to exploit the thing. A kernel build.
> You will find clear_page to be the *1st* kernel entry after cc1 and as.
> That is bad for two reasons. The time it spends in there, and the cache it
> blows.
I don't doubt that it shows real benefits; but dangerously cutting
corners usually shows benefits too. Relying on a uid at this level
feels very wrong to me - but as I said, I've not found a killer
argument against it.
And we both know that clear_page features so high in part because
it's bringing cachelines in from the cold, which are about to be
accessed again by userspace; so it's often not so bad as it appears.
Though I probably wouldn't be citing that argument if we were
talking about offloading clear_page to another engine.
Hugh
next prev parent reply other threads:[~2007-06-27 18:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-27 2:44 [patch 2/3] MAP_NOZERO - implement sys_brk2() Davide Libenzi
2007-06-27 3:07 ` Rik van Riel
2007-06-27 3:33 ` Davide Libenzi
2007-06-27 3:45 ` Ulrich Drepper
2007-06-27 4:11 ` Rik van Riel
2007-06-27 5:04 ` Ulrich Drepper
2007-06-27 3:48 ` Ulrich Drepper
2007-06-27 3:55 ` Davide Libenzi
2007-06-27 5:02 ` Ulrich Drepper
2007-06-27 12:32 ` Hugh Dickins
2007-06-27 15:59 ` Davide Libenzi
2007-06-27 17:01 ` Ulrich Drepper
2007-06-27 17:43 ` Hugh Dickins
2007-06-27 18:13 ` Davide Libenzi
2007-06-27 18:32 ` Hugh Dickins [this message]
2007-06-27 18:45 ` Davide Libenzi
2007-06-27 22:11 ` Nicholas Miell
2007-06-28 0:17 ` Davide Libenzi
2007-06-28 2:58 ` Davide Libenzi
2007-06-30 7:52 ` Andrew Morton
2007-06-27 18:52 ` Ulrich Drepper
2007-06-27 19:32 ` Hugh Dickins
2007-06-27 19:00 ` Rik van Riel
2007-06-27 19:22 ` Davide Libenzi
2007-06-27 16:05 ` Davide Libenzi
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=Pine.LNX.4.64.0706271921280.29060@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=blaisorblade@yahoo.it \
--cc=davidel@xmailserver.org \
--cc=drepper@gmail.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).