From: Minchan Kim <minchan.kim@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan.kim@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH -mmotm-2009-12-10-17-19] Prevent churning of zero page in LRU list.
Date: Mon, 28 Dec 2009 13:09:26 +0900 [thread overview]
Message-ID: <20091228130926.6874d7b2.minchan.kim@barrios-desktop> (raw)
In-Reply-To: <4B38246C.3020209@redhat.com>
Hi, Rik.
On Sun, 27 Dec 2009 22:22:20 -0500
Rik van Riel <riel@redhat.com> wrote:
> On 12/27/2009 09:53 PM, Minchan Kim wrote:
> >
> > VM doesn't add zero page to LRU list.
> > It means zero page's churning in LRU list is pointless.
> >
> > As a matter of fact, zero page can't be promoted by mark_page_accessed
> > since it doesn't have PG_lru.
> >
> > This patch prevent unecessary mark_page_accessed call of zero page
> > alghouth caller want FOLL_TOUCH.
> >
> > Signed-off-by: Minchan Kim<minchan.kim@gmail.com>
>
> The code looks correct, but I wonder how frequently we run into
> the zero page in this code, vs. how much the added cost is of
> having this extra code in follow_page.
>
> What kind of problem were you running into that motivated you
> to write this patch?
I didn't have experienced any problem in this case.
In fact, I found that while trying to make patch smap_pte_change.
Long time ago when we have a zero page, we regards it to file_rss.
So while we see the smaps, vm_normal_page returns zero page and we can
calculate it properly with PSS.
But now we don't acccout zero page to file_rss.
I am not sure we have to account it with file_rss.
So I think now smaps_pte_range's resident count routine also is changed.
Anyway, I think my patch doesn't have much cost since many customers of
follow_page are already not a fast path.
I tend to agree with your opinion "How frequently we runt into the zero page?"
But my thought GUP is export function which can be used for anything by anyone.
Thanks for the review, Rik.
>
> --
> All rights reversed.
--
Kind regards,
Minchan Kim
--
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-12-28 4:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-28 2:53 Minchan Kim
2009-12-28 2:57 ` KAMEZAWA Hiroyuki
2009-12-28 3:18 ` KOSAKI Motohiro
2009-12-28 3:22 ` Rik van Riel
2009-12-28 3:56 ` Balbir Singh
2009-12-28 3:57 ` Balbir Singh
2009-12-28 4:12 ` Rik van Riel
2009-12-28 4:17 ` Balbir Singh
2009-12-28 4:09 ` Minchan Kim [this message]
2009-12-30 17:03 ` Hugh Dickins
2009-12-31 2:26 ` Minchan Kim
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=20091228130926.6874d7b2.minchan.kim@barrios-desktop \
--to=minchan.kim@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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