On Sat 10-09-16 21:55:49, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > > > Do we want to thaw OOM victims from the beginning? If the freezer > > > > depends on CONFIG_MMU=y , we don't need to thaw OOM victims. > > > > > > We want to thaw them, at least at this stage, because the task might be > > > sitting on a memory which is not reclaimable by the oom reaper (e.g. > > > different buffers of file descriptors etc.). > > I haven't heard an answer to the question whether the freezer depends on > CONFIG_MMU=y. But I assume the answer is yes here. I do not think it depends on CONFIG_MMU. At least CGROUP_FREEZER depends on CONFIG_CGROUPS and that doesn't seem to have any direct dependency on MMU. > > > > If you worry about tasks which are sitting on a memory which is not > > reclaimable by the oom reaper, why you don't worry about tasks which > > share mm and do not share signal (i.e. clone(CLONE_VM && !CLONE_SIGHAND) > > tasks) ? Thawing only tasks which share signal is a halfway job. > > > > Here is a different approach which does not thaw tasks as of mark_oom_victim() > but thaws tasks as of oom_killer_disable(). I think that we don't need to > distinguish OOM victims and killed/exiting tasks when we disable the OOM > killer, for trying to reclaim as much memory as possible is preferable for > reducing the possibility of memory allocation failure after the OOM killer > is disabled. This makes the oom_killer_disable suspend specific which is imho not necessary. While we do not have any other user outside of the suspend path right now and I hope we will not need any in a foreseeable future there is no real reason to do a hack like this if we can make the implementation suspend independent. > Compared to your approach > > > include/linux/sched.h | 2 +- > > kernel/exit.c | 38 ++++++++++++++++++++++++++++---------- > > kernel/freezer.c | 3 ++- > > mm/oom_kill.c | 29 +++++++++++++++++------------ > > 4 files changed, 48 insertions(+), 24 deletions(-) > > , my approach does not touch exit logic. I consider the exit path changes so miniscule that trading it with pm specific code in the oom sounds like a worse solution. Well, all that assuming that the actual change is correct, of course. -- 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>