Re: [RFC][PATCH 1/3] tracking dirty pages in shared mappings -V4

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Fri, 2006-05-12 at 18:04 +1000, Nick Piggin wrote:
> Peter Zijlstra wrote:
> 
> >On Thu, 2006-05-11 at 21:30 -0700, Andrew Morton wrote:
> >
> >>Nick Piggin <piggin@cyberone.com.au> wrote:
> >>
> >>> >So let's see.  We take a write fault, we mark the page dirty then we return
> >>> >to userspace which will proceed with the write and will mark the pte dirty.
> >>> >
> >>> >Later, the VM will write the page out.
> >>> >
> >>> >Later still, the pte will get cleaned by reclaim or by munmap or whatever
> >>> >and the page will be marked dirty and the page will again be written out. 
> >>> >Potentially needlessly.
> >>> >
> >>>
> >>> page_wrprotect also marks the page clean,
> >>>
> >>Oh.  I missed that when reading the comment which describes
> >>page_wrprotect() (I do go on).
> >>
> >
> >Yes, this name is not the best of names :-(
> >
> >I was aware of this, but since in my mind the counting through
> >protection 
> >faults was the prime idea, I stuck to page_wrprotect().
> >
> >But I'm hard pressed to come up with a better one. Nick proposes:
> > page_mkclean()
> >But that also doesn't cover the whole of it from my perspective.
> >
> 
> What's your perspective?
> 
> With mmap shared accounting, the _whole VM's_ perspective is that clean
> MAP_SHARED ptes are marked readonly.
> 
> The logical operation is marking the page's ptes clean. The VM mechanism
> also marks the ptes readonly as a side effect of that. Think about it:
> writeback does not want to make the page write protected, it wants to make
> it clean.

As said, I was looking at the added functionality on its own; that is, 
counting dirty pages by trapping write faults.

However your view; the big picture; does make more sense. I shall
rename.




--
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>