Re: mm: dirty page problem

[xue yong]

I did some search in the changlogs between 2..6.16 adn 2.6.19.
I found this in http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.19

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
        (vm_flags & (VM_WRITE|VM_SHARED)) == (VM_WRITE|VM_SHARED)
     - it is not a 'special' mapping
        (vm_flags & (VM_PFNMAP|VM_INSERTPAGE)) == 0
     - the backing_dev_info is cap_account_dirty
        mapping_cap_account_dirty(vma->vm_file->f_mapping)
     - 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 2.6.16.54), 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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/