On Thu 03-08-17 16:53:40, Tetsuo Handa wrote: > Michal Hocko wrote: > > > We don't need to give up task_will_free_mem(current) without trying > > > allocation from memory reserves. We will need to select next OOM victim > > > only when allocation from memory reserves did not help. > > > > > > Thus, this patch allows task_will_free_mem(current) to ignore MMF_OOM_SKIP > > > for once so that task_will_free_mem(current) will not start selecting next > > > OOM victim without trying allocation from memory reserves. > > > > As I've already said this is an ugly hack and once we have > > http://lkml.kernel.org/r/20170727090357.3205-2-mhocko@xxxxxxxxxx merged > > then it even shouldn't be needed because _all_ threads of the oom victim > > will have an instant access to memory reserves. > > > > So I do not think we want to merge this. > > > > No, we still want to merge this, for 4.8+ kernels which won't get your patch > backported will need this. Even after your patch is merged, there is a race > window where allocating threads are between after gfp_pfmemalloc_allowed() and > before mutex_trylock(&oom_lock) in __alloc_pages_may_oom() which means that > some threads could call out_of_memory() and hit this task_will_free_mem(current) > test. Ignoring MMF_OOM_SKIP for once is still useful. I disagree. I am _highly_ skeptical this is a stable material. The mentioned test case is artificial and the source of the problem is somewhere else. Moreover the culprit is somewhere else. It is in the oom reaper setting MMF_OOM_SKIP too early and it should be addressed there. Do not add workarounds where they are not appropriate. -- Michal Hocko SUSE Labs -- 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>
