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

From: David Rientjes
Date: Mon Aug 24 2015 - 17:04:35 EST


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 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/