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