Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim
From: Michal Hocko
Date: Mon Sep 12 2016 - 05:11:49 EST
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
> > 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.