[+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>