lkml.org 
[lkml]   [2010]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/10] vmscan: Kick flusher threads to clean pages when reclaim is encountering dirty pages
    On Mon, Sep 13, 2010 at 09:48:45PM +0800, Wu Fengguang wrote:
    > > + /*
    > > + * If reclaim is encountering dirty pages, it may be because
    > > + * dirty pages are reaching the end of the LRU even though the
    > > + * dirty_ratio may be satisified. In this case, wake flusher
    > > + * threads to pro-actively clean up to a maximum of
    > > + * 4 * SWAP_CLUSTER_MAX amount of data (usually 1/2MB) unless
    > > + * !may_writepage indicates that this is a direct reclaimer in
    > > + * laptop mode avoiding disk spin-ups
    > > + */
    > > + if (file && nr_dirty_seen && sc->may_writepage)
    > > + wakeup_flusher_threads(nr_writeback_pages(nr_dirty));
    >
    > wakeup_flusher_threads() works, but seems not the pertinent one.
    >
    > - locally, it needs some luck to clean the pages that direct reclaim is waiting on

    There is a certain amount of luck involved but it's depending on there being a
    correlation between old inodes and old pages on the LRU list. As long as that
    correlation is accurate, some relevant pages will get cleaned. Testing on
    previously released versions of this patch did show that the percentage of
    dirty pages encountered during reclaim were reduced as a result of this patch.

    > - globally, it cleans up some dirty pages, however some heavy dirtier
    > may quickly create new ones..
    >
    > So how about taking the approaches in these patches?
    >
    > - "[PATCH 4/4] vmscan: transfer async file writeback to the flusher"
    > - "[PATCH 15/17] mm: lower soft dirty limits on memory pressure"
    >

    There is a lot going on in those patches. It's going to take me a while to
    figure them out and formulate an opinion.

    > In particular the first patch should work very nicely with memcg, as
    > all pages of an inode typically belong to the same memcg. So doing
    > write-around helps clean lots of dirty pages in the target LRU list in
    > one shot.
    >

    It might but as there is also a correlation between old dirty inodes and
    the location of dirty pages, it is tricky to predict if it is better and
    if so, by how much.

    --
    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab


    \
     
     \ /
      Last update: 2010-09-13 16:13    [W:0.021 / U:148.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site