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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
