Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim

On Sat 10-09-16 21:55:49, Tetsuo Handa wrote:

Tetsuo Handa wrote:

quoted

quoted

quoted

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.

quoted

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

quoted

 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>