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