Michal Hocko wrote: > On Tue 19-12-17 23:36:02, Tetsuo Handa wrote: > > If http://lkml.kernel.org/r/20171219114012.GK2787@xxxxxxxxxxxxxx , > > is direction below acceptable? > > The same applies here. You are touching the way how the memory reserves > are access in non-trivial way. You better have a very good reason for > that. So far you keep playing with different corner cases while you keep > showing that you do not really want to understand a bigger picture. This > can end up in regressions easily. Any OOM-killed thread is allowed to use memory reserves up to ALLOC_OOM watermark. How can allowing all OOM-killed threads to try ALLOC_OOM watermark cause regressions? Commit cd04ae1e2dc8e365 ("mm, oom: do not rely on TIF_MEMDIE for memory reserves access") changed from only TIF_MEMDIE thread to all threads in one thread group. But we don't call it a regression. My proposal is nothing but changes from all threads in one thread group to all threads in all thread groups (which were killed due to sharing the victim's mm). And how can we call it a regression? > Let me repeat something I've said a > long ago. We do not optimize for corner cases. We want to survive but if > an alternative is to kill another task then we can live with that. > Setting MMF_OOM_SKIP before all OOM-killed threads try memory reserves leads to needlessly selecting more OOM victims. Unless any OOM-killed thread fails to satisfy allocation even with ALLOC_OOM, no OOM-killed thread needs to select more OOM victims. Commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip oom_reaped tasks") obviously broke it, which is exactly a regression. -- 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>
