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

[Nick Piggin <piggin@cyberone.com.au>]

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.

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