Messages in this thread | | | Date | Tue, 30 Jun 2009 01:41:12 -0700 (PDT) | From | David Rientjes <> | Subject | Re: upcoming kerneloops.org 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.
| |