On Tue, Nov 24, 2015 at 10:47:09AM +0100, Michal Hocko wrote: > Besides that there is no other reliable warning that we are getting > _really_ short on memory unlike when the allocation failure is > allowed. OOM killer report might be missing because there was no actual > killing happening. This is why I would like to see that warning generalized, and not just for __GFP_NOFAIL. We have allocations other than explicit __GFP_NOFAIL that will loop forever in the allocator, and when this deadlocks the machine all we see is other tasks hanging, but not the culprit. If we were to get a backtrace of some task in the allocator that is known to hold locks, suddenly all the other hung tasks will make sense, and it will clearly distinguish such an allocator deadlock from other issues. Do you remember the patch you proposed at LSF about failing requests after looping a certain (configurable) number of times? Well, instead of failing them, it would be good to start WARNING after a certain # of loops when we know we won't quit (implicit or explicit NOFAIL). [ Kind of like fs/xfs/kmem::kmem_alloc() does, only that that is currently dead code due to our looping inside the allocator. ] -- 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>