lkml.org 
[lkml]   [2009]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -mmotm-2009-12-10-17-19] Prevent churning of zero page in LRU list.
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


\
 
 \ /
  Last update: 2009-12-28 05:13    [W:0.115 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site