On Tue 19-07-16 20:43:32, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Tue 19-07-16 19:36:40, Tetsuo Handa wrote: > > > Michal Hocko wrote: [...] > > > > And that being said. If you strongly disagree with the wording then what > > > > about the following: > > > > " > > > > In order to help a forward progress for the OOM killer, make sure that > > > > this really rare cases will not get into the way and hide the mm from the > > > > oom killer by setting MMF_OOM_REAPED flag for it. oom_scan_process_thread > > > > will ignore any TIF_MEMDIE task if it has MMF_OOM_REAPED flag set to catch > > > > these oom victims. > > > > > > > > After this patch we should guarantee a forward progress for the OOM killer > > > > even when the selected victim is sharing memory with a kernel thread or > > > > global init as long as the victims mm is still alive. > > > > " > > > > > > No, I don't like "as long as the victims mm is still alive" exception. > > > > Why? Because of the wording or in principle? > > Making a _guarantee without exceptions now_ can allow other OOM livelock handlings I am not convinced this particular thing would be the last piece in the puzzle... And as already said before. Can we wait for the merge window with the next changes please? I really do not want end up in a situation where we would have too many oom fixes in flight again. There is no reason to hurry. -- 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>