[lkml]   [2007]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 03/29] mm: slb: add knowledge of reserve pages
    On Friday 14 December 2007 07:39, Peter Zijlstra wrote:
    > Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to
    > allocation contexts that are entitled to it. This is done to ensure
    > reserve pages don't leak out and get consumed.

    Tighter definitions of "leak out" and "get consumed" would be helpful
    here. As I see it, the chain of reasoning is:

    * Any MEMALLOC mode allocation must have come from a properly
    throttled path and has a finite lifetime that must eventually
    produce writeout progress.

    * Since the transaction that made the allocation was throttled and
    must have a finite lifetime, we know that it must eventually return
    the resources it consumed to the appropriate resource pool.

    Now, I think what you mean by "get consumed" and "leak out" is: "become
    pinned by false sharing with other allocations that do not guarantee
    that they will be returned to the resource pool". We can say "pinned"
    for short.

    So you are attempting to prevent slab pages from becoming pinned by
    users that do not obey the reserve management rules, which I think your
    approach achieves. However...

    Note that false sharing of slab pages is still possible between two
    unrelated writeout processes, both of which obey rules for their own
    writeout path, but the pinned combination does not. This still leaves
    a hole through which a deadlock may slip.

    My original solution was simply to allocate a full page when drawing
    from the memaloc reserve, which may use a tad more reserve, but makes
    it possible to prove the algorithm correct.



     \ /
      Last update: 2007-12-14 23:53    [W:0.020 / U:5.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site