On Wed, 30 Sep 2015, Tetsuo Handa wrote: > If we choose only 1 OOM victim, the possibility of hitting this memory > unmapping livelock is (say) 1%. But if we choose multiple OOM victims, the > possibility becomes (almost) 0%. And if we still hit this livelock even > after choosing many OOM victims, it is time to call panic(). > Again, this is a fundamental disagreement between your approach of randomly killing processes hoping that we target one that can make a quick exit vs. my approach where we give threads access to memory reserves after reclaim has failed in an oom livelock so they at least make forward progress. We're going around in circles. > (Well, do we need to change __alloc_pages_slowpath() that OOM victims do not > enter direct reclaim paths in order to avoid being blocked by unkillable fs > locks?) > OOM victims shouldn't need to enter reclaim, and there have been patches before to abort reclaim if current has a pending SIGKILL, if they have access to memory reserves. Nothing prevents the victim from already being in reclaim, however, when it is killed. > > Perhaps this is an argument that we need to provide access to memory > > reserves for threads even for !__GFP_WAIT and !__GFP_FS in such scenarios, > > but I would wait to make that extension until we see it in practice. > > I think that GFP_ATOMIC allocations already access memory reserves via > ALLOC_HIGH priority. > Yes, that's true. It doesn't help for GFP_NOFS, however. It may be possible that GFP_ATOMIC reserves have been depleted or there is a GFP_NOFS allocation that gets stuck looping forever that doesn't get the ability to allocate without watermarks. I'd wait to see it in practice before making this extension since it relies on scanning the tasklist. -- 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>