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. -- 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>
