On Tue, Jan 06 2015, Michal Hocko wrote: > - As it turned out recently GFP_KERNEL mimicing GFP_NOFAIL for !costly > allocation is sometimes kicking us back because we are basically > creating an invisible lock dependencies which might livelock the whole > system under OOM conditions. > That leads to attempts to add more hacks into the OOM killer > which is tricky enough as is. Changing the current state is > quite risky because we do not really know how many places in the > kernel silently depend on this behavior. As per Johannes attempt > (http://marc.info/?l=linux-mm&m=141932770811346) it is clear that > we are not yet there! I do not have very good ideas how to deal with > this unfortunatelly... We've internally been fighting similar deadlocks between memcg kmem accounting and memcg oom killer. I wouldn't call it a very good idea, because it falls in the realm of further complicating the oom killer, but what about introducing an async oom killer which runs outside of the context of the current task. An async killer won't hold any locks so it won't block the indented oom victim from terminating. After queuing a deferred oom kill the allocating thread would then be able to dip into memory reserves to satisfy its too-small-to-fail allocation. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>