lkml.org 
[lkml]   [2016]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 13/13] mm, compaction: fix and improve watermark handling
    On Wed, May 18, 2016 at 04:27:53PM +0200, Michal Hocko wrote:
    > > > > - __compaction_suitable() then checks the low watermark plus a (2 << order) gap
    > > > > to decide if there's enough free memory to perform compaction. This check
    > > >
    > > > And this was a real head scratcher when I started looking into the
    > > > compaction recently. Why do we need to be above low watermark to even
    > > > start compaction. Compaction uses additional memory only for a short
    > > > period of time and then releases the already migrated pages.
    > > >
    > >
    > > Simply minimising the risk that compaction would deplete the entire
    > > zone. Sure, it hands pages back shortly afterwards. At the time of the
    > > initial prototype, page migration was severely broken and the system was
    > > constantly crashing. The cautious checks were left in place after page
    > > migration was fixed as there wasn't a compelling reason to remove them
    > > at the time.
    >
    > OK, then moving to min_wmark + bias from low_wmark should work, right?

    Yes. I did recall there was another reason but it's marginal. I didn't
    want compaction isolation free pages to artifically push a process into
    direct reclaim but given that we are likely under memory pressure at
    that time anyway, it's unlikely that compaction is the sole reason
    processes are entering direct reclaim.

    --
    Mel Gorman
    SUSE Labs

    \
     
     \ /
      Last update: 2016-05-18 17:01    [W:4.720 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site