On Fri, 21 Aug 2015, Michal Hocko wrote: > There might be many threads waiting for the allocation and this can lead > to quick oom reserves depletion without releasing resources which are > holding back the oom victim. As Tetsuo has shown, such a load can be > generated from the userspace without root privileges so it is much > easier to make the system _completely_ unusable with this patch. Not that > having an OOM deadlock would be great but you still have emergency tools > like sysrq triggered OOM killer to attempt to sort the situation out. > Once your are out of reserves nothing will help you, though. So I think it > is a bad idea to give access to reserves without any throttling. > I don't believe a solution that requires admin intervention is maintainable. It would be better to reboot when memory reserves are fully depleted. > Johannes' idea to give a partial access to memory reserves to the task > which has invoked the OOM killer was much better IMO. That's what this patch does, just without the "partial." Processes are required to reclaim and then invoke the oom killler every time an allocation is made using memory reserves with this approach after the expiration has lapsed. We can discuss only allowing partial access to memory reserves equal to ALLOC_HARD | ALLOC_HARDER, or defining a new watermark, but I'm concerned about what happens when that threshold is reached and the oom killer is still livelocked. It would seem better to attempt recovery at whatever cost and then panic if fully depleted. -- 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>