[lkml]   [2009]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: upcoming item: get_page_from_freelist
    On Tue, 30 Jun 2009, Nick Piggin wrote:

    > > I'd agree with Mel's added check for TIF_MEMDIE upon returning from the
    > > oom killer, but only for __GFP_NOMEMALLOC.
    > NOMEMALLOC indeed should always be kept away from memalloc/memdie
    > reserves. That's how it should have worked when I added it (but
    > I may have forgotten TIF_MEMDIE, I can't remember).

    Yeah, so if test_thread_flag(TIF_MEMDIE) and __GFP_NOMEMALLOC, then it
    makes sense to return NULL immediately following the call to the oom
    killer for !__GFP_NOFAIL since retrying the allocation is pointless
    (reclaim failed already and TIF_MEMDIE doesn't help us on the next
    attempt) at that time.

    > > The oom killer currently is a no-op if any eligible task has TIF_MEMDIE,
    > > so this would require adding an oom killer timeout so that if a task fails
    > > to exit after a predefined period, TIF_MEMDIE is cleared and the task is
    > > marked to no longer be selected (which would require an addition to
    > > task_struct) although it may have already completely depleted memory
    > > reserves.
    > It wouldn't have to be a timeout, it could be a call back to the
    > oom killer.

    Calling the oom killer won't do anything since it will not kill another
    task while another has TIF_MEMDIE to protect those memory reserves and
    give the oom killed task a chance to exit.

    Panicking when a thread with TIF_MEMDIE set cannot find any memory and the
    allocation is __GFP_NOFAIL makes sense, but only for order 0.

     \ /
      Last update: 2009-06-30 10:43    [W:0.031 / U:18.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site