lkml.org 
[lkml]   [2009]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Fix dirty page accounting in redirty_page_for_writepage()
    On Wed, 29 Apr 2009 19:25:46 -0400
    Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

    > Basically, the following execution :
    >
    > dd if=/dev/zero of=/tmp/testfile
    >
    > will slowly fill _all_ ram available without taking into account memory
    > pressure.
    >
    > This is because the dirty page accounting is incorrect in
    > redirty_page_for_writepage.
    >
    > This patch adds missing dirty page accounting in redirty_page_for_writepage().

    The patch changes __set_page_dirty_nobuffers(), not
    redirty_page_for_writepage().

    __set_page_dirty_nobuffers() has a huge number of callers.

    > --- linux-2.6-lttng.orig/mm/page-writeback.c 2009-04-29 18:14:48.000000000 -0400
    > +++ linux-2.6-lttng/mm/page-writeback.c 2009-04-29 18:23:59.000000000 -0400
    > @@ -1237,6 +1237,12 @@ int __set_page_dirty_nobuffers(struct pa
    > if (!mapping)
    > return 1;
    >
    > + /*
    > + * Take care of setting back page accounting correctly.
    > + */
    > + inc_zone_page_state(page, NR_FILE_DIRTY);
    > + inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
    > +
    > spin_lock_irq(&mapping->tree_lock);
    > mapping2 = page_mapping(page);
    > if (mapping2) { /* Race with truncate? */
    >

    But __set_page_dirty_nobuffers() calls account_page_dirtied(), which
    already does the above two operations. afacit we're now
    double-accounting.

    Now, it's possible that the accounting goes wrong very occasionally in
    the "/* Race with truncate? */" case. If the truncate path clears the
    page's dirty bit then it will decrement the dirty-page accounting, but
    this code path will fail to perform the increment of the dirty-page
    accounting. IOW, once this function has set PG_Dirty, it is committed
    to altering some or all of the page-dirty accounting.

    But afacit your test case will not trigger the race-with-truncate anyway?

    Can you determine at approximately what frequency (pages-per-second)
    this accounting leak is occurring in your test?



    \
     
     \ /
      Last update: 2009-04-30 02:07    [W:0.030 / U:30.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site