Re: [PATCH 1/5] mm: Add __GFP_NO_OOM_KILL flag

[David Rientjes]

On Thu, 7 May 2009, Andrew Morton wrote:

> > > All of your tasks are in D state other than kthreads, right?  That means 
> > > they won't be in the oom killer (thus no zones are oom locked), so you can 
> > > easily do this
> > > 
> > > 	struct zone *z;
> > > 	for_each_populated_zone(z)
> > > 		zone_set_flag(z, ZONE_OOM_LOCKED);
> > > 
> > > and then
> > > 
> > > 	for_each_populated_zone(z)
> > > 		zone_clear_flag(z, ZONE_OOM_LOCKED);
> > > 
> > > The serialization is done with trylocks so this will never invoke the oom 
> > > killer because all zones in the allocator's zonelist will be oom locked.
> > > 
> > > Why does this not work for you?
> > 
> > Well, it might work too, but why are you insisting?  How's it better than
> > __GFP_NO_OOM_KILL, actually?
> > 
> > Andrew, what do you think about this?
> 
> I don't think I understand the proposal.  Is it to provide a means by
> which PM can go in and set a state bit against each and every zone?  If
> so, that's still a global boolean, only messier.
> 

Why can't it be global while preallocating memory for hibernation since 
nothing but kthreads could allocate at this point and if the system is oom 
then the oom killer wouldn't be able to do anything anyway since it can't 
kill them?

The fact is that _all_ allocations here are implicitly __GFP_NO_OOM_KILL 
whether it specifies it or not since the oom killer would simply kill a 
task in D state which can't exit or free memory and subsequent allocations 
would make the oom killer a no-op because there's an eligible task with 
TIF_MEMDIE set.  The only thing you're saving with __GFP_NO_OOM_KILL is 
calling the oom killer in a first place and killing an unresponsive task 
but that would have to happen anyway when thawed since the system is oom 
(or otherwise lockup for GFP_KERNEL with order < PAGE_ALLOC_COSTLY_ORDER).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/