Re: mm: dirty page problem

From: xue yong
Date: Tue Jun 23 2009 - 05:02:44 EST

I did some search in the changlogs between 2..6.16 adn 2.6.19.
I found this in

and I concluded that the kernel below 2.6.19 can't tracking shared
dirty pages, am I right?

commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
Author: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Date: Mon Sep 25 23:30:58 2006 -0700

[PATCH] mm: balance dirty pages

Now that we can detect writers of shared mappings, throttle them.
Avoids OOM
by surprise.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Cc: Hugh Dickins <hugh@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>

commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89
Author: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Date: Mon Sep 25 23:30:57 2006 -0700

[PATCH] mm: tracking shared dirty pages

Tracking of dirty pages in shared writeable mmap()s.

The idea is simple: write protect clean shared writeable pages, catch the
write-fault, make writeable and set dirty. On page write-back clean all the
PTE dirty bits and write protect them once again.

The implementation is a tad harder, mainly because the default
backing_dev_info capabilities were too loosely maintained. Hence it is not
enough to test the backing_dev_info for cap_account_dirty.

The current heuristic is as follows, a VMA is eligible when:
- its shared writeable
- it is not a 'special' mapping
(vm_flags & (VM_PFNMAP|VM_INSERTPAGE)) == 0
- the backing_dev_info is cap_account_dirty
- f_op->mmap() didn't change the default page protection

Page from remap_pfn_range() are explicitly excluded because their COW
semantics are already horrid enough (see vm_normal_page() in
do_wp_page()) and
because they don't have a backing store anyway.

mprotect() is taught about the new behaviour as well. However it overrides
the last condition.

Cleaning the pages on write-back is done with page_mkclean() a new
rmap call.
It can be called on any page, but is currently only implemented for mapped
pages, if the page is found the be of a VMA that accounts dirty
pages it will
also wrprotect the PTE.

Finally, in fs/buffers.c:try_to_free_buffers(); remove
clear_page_dirty() from
under ->private_lock. This seems to be safe, since ->private_lock
is used to
serialize access to the buffers, not the page itself. This is
needed because
clear_page_dirty() will call into page_mkclean() and would thereby violate
locking order.

[dhowells@xxxxxxxxxx: Provide a page_mkclean() implementation for NOMMU]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Cc: Hugh Dickins <hugh@xxxxxxxxxxx>
Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>

On Tue, Jun 23, 2009 at 4:17 PM, xue yong<ultraice.kernel@xxxxxxxxx> wrote:
> I wrote a test program. It  mmap  a file and do some write, so some
> pages become dirty.
> and then I do "cat /proc/meminfo", so I get dirty pages that I have
> written. this happened in my home
> computer with debian, self compiled kernel 2.6.18-5 installed.
> but in my company, on the servers (suse kernel, after the
> test program have written the data, there was no change in
> dirty pages column of "cat /proc/meminfo" 's output. after I killed
> the test program, the dirty pages changed immediately.
> I dont know why such different behavior, can you help me?
> becauce we want a program mmap some files, and after the files'
> contents were changed, the OS can write out these dirty
> data back to disk periodly.
> Best regards!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at