• Johannes Weiner's avatar
    mm: memcontrol: try harder to set a new memory.high · 8c8c383c
    Johannes Weiner authored
    Setting a memory.high limit below the usage makes almost no effort to
    shrink the cgroup to the new target size.
    
    While memory.high is a "soft" limit that isn't supposed to cause OOM
    situations, we should still try harder to meet a user request through
    persistent reclaim.
    
    For example, after setting a 10M memory.high on an 800M cgroup full of
    file cache, the usage shrinks to about 350M:
    
      + cat /cgroup/workingset/memory.current
      841568256
      + echo 10M
      + cat /cgroup/workingset/memory.current
      355729408
    
    This isn't exactly what the user would expect to happen. Setting the
    value a few more times eventually whittles the usage down to what we
    are asking for:
    
      + echo 10M
      + cat /cgroup/workingset/memory.current
      104181760
      + echo 10M
      + cat /cgroup/workingset/memory.current
      31801344
      + echo 10M
      + cat /cgroup/workingset/memory.current
      10440704
    
    To improve this, add reclaim retry loops to the memory.high write()
    callback, similar to what we do for memory.max, to make a reasonable
    effort that the usage meets the requested size after the call returns.
    
    Afterwards, a single write() to memory.high is enough in all but extreme
    cases:
    
      + cat /cgroup/workingset/memory.current
      841609216
      + echo 10M
      + cat /cgroup/workingset/memory.current
      10182656
    
    790M is not a reasonable reclaim target to ask of a single reclaim
    invocation.  And it wouldn't be reasonable to optimize the reclaim code
    for it.  So asking for the full size but retrying is not a bad choice
    here: we express our intent, and benefit if reclaim becomes better at
    handling larger requests, but we also acknowledge that some of the
    deltas we can encounter in memory_high_write() are just too ridiculously
    big for a single reclaim invocation to manage.
    
    Link: http://lkml.kernel.org/r/20191022201518.341216-2-hannes@cmpxchg.orgSigned-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
    Acked-by: default avatarMichal Hocko <mhocko@suse.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    8c8c383c
memcontrol.c 189 KB