lkml.org 
[lkml]   [2020]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high
    On Wed, Feb 19, 2020 at 11:31:39AM -0800, Andrew Morton wrote:
    > But what was the nature of these stalls? If they were "stuck in D
    > state waiting for something" then that's throttling. If they were
    > "unexpected bursts of in-kernel CPU activity" then I see a better case.

    It was both.

    However, the workload was able to perform with no direct reclaim
    activity and no stalls, while memory.high semantics were never
    violated. This means that allocation rate was not outstripping reclaim
    rate, just that both of these things happened in bursts and sputters.

    If the workload isn't exceeding the memory.high grace buffer, it seems
    unnecessary to make it wait behind a reclaim invocation that gets
    delayed on IO but will succeed before the workload comes back for the
    next allocation. We can just let it get on with its thing, actually
    work with the memory it just obtained, while background reclaim will
    free pages as they become reclaimable. This is a win-win situation.

    \
     
     \ /
      Last update: 2020-02-19 22:34    [W:4.715 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site