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. 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
