lkml.org 
[lkml]   [2015]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/9] mm: improve OOM mechanism v2
    From
    Date
    Michal Hocko wrote:
    > I mean we should eventually fail all the allocation types but GFP_NOFS
    > is coming from _carefully_ handled code paths which is an easier starting
    > point than a random code path in the kernel/drivers. So can we finally
    > move at least in this direction?

    I agree that all the allocation types can fail unless GFP_NOFAIL is given.
    But I also expect that all the allocation types should not fail unless
    order > PAGE_ALLOC_COSTLY_ORDER or GFP_NORETRY is given or chosen as an OOM
    victim.

    We already experienced at Linux 3.19 what happens if !__GFP_FS allocations
    fails. out_of_memory() is called by pagefault_out_of_memory() when 0x2015a
    (!__GFP_FS) allocation failed. This looks to me that !__GFP_FS allocations
    are effectively OOM killer context. It is not fair to kill the thread which
    triggered a page fault, for that thread may not be using so much memory
    (unfair from memory usage point of view) or that thread may be global init
    (unfair because killing the entire system than survive by killing somebody).
    Also, failing the GFP_NOFS/GFP_NOIO allocations which are not triggered by
    a page fault generally causes more damage (e.g. taking filesystem error
    action) than survive by killing somebody. Therefore, I think we should not
    hesitate invoking the OOM killer for !__GFP_FS allocation.

    > > Likewise, there is possibility that such memory reserve is used by threads
    > > which the OOM victim is not waiting for, for malloc() + memset() causes
    > > __GFP_FS allocations.
    >
    > We cannot be certain without complete dependency tracking. This is
    > just a heuristic.

    Yes, we cannot be certain without complete dependency tracking. And doing
    complete dependency tracking is too expensive to implement. Dave is
    recommending that we should focus on not to trigger the OOM killer than
    how to handle corner cases in OOM conditions, isn't he? I still believe that
    choosing more OOM victims upon timeout (which is a heuristic after all) and
    invoking the OOM killer for !__GFP_FS allocations are the cheapest and least
    surprising. This is something like automatically and periodically pressing
    SysRq-f on behalf of the system administrator when memory allocator cannot
    recover from low memory situation.


    \
     
     \ /
      Last update: 2015-04-30 12:21    [W:2.535 / U:1.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site