Re: [PATCH -mm] rmap: move exclusively owned pages to own anon_vmain do_wp_page

[Minchan Kim]

Hi, Rik. 
It's time too late to review. :)
But I remain my comments for record in future. 

On Thu, 2010-01-28 at 01:43 -0500, Rik van Riel wrote:
> When the parent process breaks the COW on a page, both the original
> and the new page end up in that same anon_vma.  Generally this won't
> be a problem, but for some workloads it could preserve the O(N) rmap
> scanning complexity.
> A simple fix is to ensure that, when a page gets reused in do_wp_page,
> because we already are the exclusive owner, the page gets moved to our
> own exclusive anon_vma.

I want to modify this description following as for clarity

When the parent process breaks the COW on a page, both the original which
is mapped at child and the new page which is mapped parent end up in that
same anon_vma. Generally this won't be a problem, but for some workloads it
could preserve the O(N) rmap scanning complexity.

A simple fix is to ensure that, when a page which is mapped child gets
reused in do_wp_page, because we already are the exclusive owner, the
page gets moved to our own exclusive child's anon_vma. 


> Signed-off-by: Rik van Riel <riel@xxxxxxxxxx>
Reviewed-by: Minchan Kim <minchan.kim@xxxxxxxxx>

Let me have a question for my understanding.

Still, don't we have a probability of O(N) in case of parent's page 
at worst case?

What I say is following as.

P : parent's VMA, C : child's VMA
L : live ( target page is linked into parent's anon_vma)
D : dead ( new page was linked into child's anon_vma with this patch
           so this vma doesn't have our target page)

             P      C      C      C      C
anon_vma -> vma -> vma -> vma -> vma -> vma 
             L      D      D      D      L

Such above case, for reclaiming the page, we have to traverse whole list. 

If I miss something, pz correct me. :)

-- 
Kind regards,
Minchan Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/