Re: upcoming kerneloops.org item: get_page_from_freelist

[Nick Piggin <npiggin@suse.de>]

On Tue, Jun 30, 2009 at 01:41:12AM -0700, David Rientjes wrote:
> 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.

I don't see the importance of calling the oom killer. If a thread
is TIF_MEMDIE, then we should not try to enter reclaim nor try to
call the oom killer. The oom killer has already been activated and
because it has been determined that nothing can be reclaimed...

 
> > > 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.

I don't mean the normal oom-killer path, but another call to say
"this thread got stuck, un-kill me and look for someone else to kill"
or somesuch.

 
> 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.

Why only order-0? What would you do at order>0?