[lkml]   [2009]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mm: dirty page problem
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 <>
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 <>
Cc: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>

commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89
Author: Peter Zijlstra <>
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.

[ Provide a page_mkclean() implementation for NOMMU]
Signed-off-by: Peter Zijlstra <>
Cc: Hugh Dickins <>
Signed-off-by: David Howells <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>

On Tue, Jun 23, 2009 at 4:17 PM, xue yong<> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-06-23 11:05    [W:0.050 / U:4.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site