Re: OOM kills with lots of free swap

[Vlastimil Babka <vbabka@suse.cz>]

[+CC Michal]

On 06/24/2017 01:29 AM, Luigi Semenzato wrote:
> It is fairly easy to trigger OOM-kills with almost empty swap, by
> running several fast-allocating processes in parallel.  I can
> reproduce this on many 3.x kernels (I think I tried also on 4.4 but am
> not sure).  I am hoping this is a known problem.

There was a notable OOM rework by Michal around 4.6 ?, so knowing the
state on recent kernels would be really useful.

In any case, please include the actual oom reports.

> I tried to debug this in the past, by backtracking from the call to
> the OOM code, and adding instrumentation to understand why the task
> failed to allocate (or even make progress, apparently), but my effort
> did not yield results within reasonable time.
> 
> I believe that it is possible that one task succeeds in reclaiming
> pages, and then another task takes those pages before the first task
> has a chance to get them.  But in that case the first task should
> still notice progress and should retry, correct?  Is it possible in
> theory that one task fails to allocate AND fails to make progress
> while other tasks succeed?
> 
> (I asked this question, in not so many words, in 2013, but received no answers.)
> 
> Thanks!
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>