[CCing Tetsuo - he was really concerned about the oom deadlocks and he was proposing a timeout based solution as well] On Thu 20-08-15 14:00:36, David Rientjes wrote: > On system oom, a process may fail to exit if its thread depends on a lock > held by another allocating process. > > In this case, we can detect an oom kill livelock that requires memory > allocation to be successful to resolve. > > This patch introduces an oom expiration, set to 5s, that defines how long > a thread has to exit after being oom killed. > > When this period elapses, it is assumed that the thread cannot make > forward progress without help. The only help the VM may provide is to > allow pending allocations to succeed, so it grants all allocators access > to memory reserves after reclaim and compaction have failed. 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. Johannes' idea to give a partial access to memory reserves to the task which has invoked the OOM killer was much better IMO. -- Michal Hocko SUSE Labs -- 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>