Messages in this thread | | | Subject | Re: [PATCH -mm] rmap: move exclusively owned pages to own anon_vma in do_wp_page | From | Minchan Kim <> | Date | Tue, 02 Feb 2010 00:25:18 +0900 |
| |
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@redhat.com> Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
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
| |