From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Nick Piggin <npiggin@suse.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
avi@redhat.com, akpm@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: [RFC][PATCH 0/4] ZERO PAGE again v2
Date: Fri, 10 Jul 2009 12:18:07 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0907101201280.2456@sister.anvils> (raw)
In-Reply-To: <20090708173206.GN356@random.random>
On Wed, 8 Jul 2009, Andrea Arcangeli wrote:
> On Tue, Jul 07, 2009 at 06:06:29PM +0900, KAMEZAWA Hiroyuki wrote:
> > Then, most of users will not notice that ZERO_PAGE is not available until
> > he(she) find OOM-Killer message. This is very terrible situation for me.
> > (and most of system admins.)
>
> Can you try to teach them to use KSM and see if they gain a while lot
> more from it (surely they also do some memset(dst, 0) sometime not
> only memcpy(zerosrc, dst)). Not to tell when they init to non zero
> values their arrays/matrix which is a bit harder to optimize for with
> zero page...
>
> My only dislike is that zero page requires a flood of "if ()" new
> branches in fast paths that benefits nothing but badly written app,
> and that's the only reason I liked its removal.
>
> For goodly (and badly) written scientific app there KSM that will do
> more than zeropage while dealing with matrix algorithms and such. If
> they try KSM and they don't gain a lot more free memory than with the
> zero page hack, then I agree in reintroducing it, but I guess when
> they try KSM they will ask you to patch kernel with it, instead of
> patch kernel with zeropage. If they don't gain anything more with KSM
> than with zeropage, and the kksmd overhead is too high, then it would
> make sense to use zeropage for them I agree even if it bites in the
> fast path of all apps that can't benefit from it. (not to tell the
> fact that reading zero and writing non zero back for normal apps is
> harmful as there's a double page fault generated instead of a single
> one, kksmd has a cost but zeropage isn't free either in term of page
> faults too)
Much as I like KSM, I have to agree with Avi, that if people are
wanting the ZERO_PAGE back in compute-intensive loads, then relying
on ksmd to put Humpty Dumpty together again is much too expensive a
way to go about it: ZERO_PAGE saves him from falling off the wall
in the first place, and that's much the better way to deal with it.
It might turn out in the end to be convenient to treat the ZERO_PAGE
as an "automatic" KSM page, I don't know; or we'll need to teach KSM
not to waste its time remerging instances of the ZERO_PAGE to a
zeroed KSM page. We'll worry about that once both sets in mmotm.
I didn't care for Kamezawa-san's original patchsets, seemed messy
and branchy, but it looks to be heading the right way now using
vm_normal_page (pity about arches without pte_special, oh well).
Hugh
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-07-10 10:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-07 7:51 [RFC][PATCH 0/4] ZERO PAGE again v2 KAMEZAWA Hiroyuki
2009-07-07 7:52 ` [RFC][PATCH 1/4] introduce pte_zero() KAMEZAWA Hiroyuki
2009-07-07 7:54 ` [RFC][PATCH 2/4] use ZERO_PAGE for READ fault in regular anonymous mapping KAMEZAWA Hiroyuki
2009-07-07 7:59 ` [RFC][PATCH 3/4] get_user_pages READ fault handling special cases KAMEZAWA Hiroyuki
2009-07-07 16:50 ` Linus Torvalds
2009-07-08 0:03 ` KAMEZAWA Hiroyuki
2009-07-08 1:38 ` KAMEZAWA Hiroyuki
2009-07-08 2:27 ` Linus Torvalds
2009-07-07 8:01 ` [RFC][PATCH 4/4] add get user pages nozero KAMEZAWA Hiroyuki
2009-07-07 8:47 ` [RFC][PATCH 0/4] ZERO PAGE again v2 Nick Piggin
2009-07-07 9:05 ` Avi Kivity
2009-07-07 9:18 ` KAMEZAWA Hiroyuki
2009-07-07 9:26 ` Avi Kivity
2009-07-07 9:06 ` KAMEZAWA Hiroyuki
2009-07-07 14:00 ` Nick Piggin
2009-07-07 16:59 ` Linus Torvalds
2009-07-08 6:21 ` Nick Piggin
2009-07-08 16:07 ` Linus Torvalds
2009-07-09 7:47 ` Nick Piggin
2009-07-09 17:54 ` Linus Torvalds
2009-07-10 2:09 ` Nick Piggin
2009-07-10 3:38 ` Linus Torvalds
2009-07-10 3:51 ` Nick Piggin
2009-07-08 17:32 ` Andrea Arcangeli
2009-07-09 1:12 ` KAMEZAWA Hiroyuki
2009-07-10 11:18 ` Hugh Dickins [this message]
2009-07-10 13:42 ` Andrea Arcangeli
2009-07-10 14:12 ` KAMEZAWA Hiroyuki
2009-07-10 15:16 ` Andrea Arcangeli
2009-07-10 15:32 ` KAMEZAWA Hiroyuki
2009-07-10 17:09 ` Hugh Dickins
2009-07-13 6:46 ` Nick Piggin
2009-07-13 7:24 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2009-07-07 15:50 KAMEZAWA Hiroyuki
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.0907101201280.2456@sister.anvils \
--to=hugh.dickins@tiscali.co.uk \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=avi@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=torvalds@linux-foundation.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).