Re: [patch -mm] mm, oom: add global access to memory reserves on livelock

[Michal Hocko]

[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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/