On Wed, 11 Dec 2013, Michal Hocko wrote: > > Triggering a pointless notification with PF_EXITING is rare, yet one > > pointless notification can be avoided with the patch. > > Sigh. Yes it will avoid one particular and rare race. There will still > be notifications without oom kills. >
Would you prefer doing the mem_cgroup_oom_notify() in two places instead: - immediately before doing oom_kill_process() when it's guaranteed that the kernel would have killed something, and - when memory.oom_control == 1 in mem_cgroup_oom_synchronize()? > Anyway. > Does the reclaim make any sense for PF_EXITING tasks? Shouldn't we > simply bypass charges of these tasks automatically. Those tasks will > free some memory anyway so why to trigger reclaim and potentially OOM > in the first place? Do we need to go via TIF_MEMDIE loop in the first > place? > I don't see any reason to make an optimization there since they will get TIF_MEMDIE set if reclaim has failed on one of their charges or if it results in a system oom through the page allocator's oom killer. It would be nice to ensure reclaim has had a chance to free memory in the presence of any other potential parallel memory freeing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
