From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757165AbcILJLq (ORCPT ); Mon, 12 Sep 2016 05:11:46 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38857 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755377AbcILJLo (ORCPT ); Mon, 12 Sep 2016 05:11:44 -0400 Date: Mon, 12 Sep 2016 11:11:41 +0200 From: Michal Hocko To: Tetsuo Handa Cc: linux-mm@kvack.org, rientjes@google.com, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, oleg@redhat.com, viro@zeniv.linux.org.uk Subject: Re: [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim Message-ID: <20160912091141.GD14524@dhcp22.suse.cz> References: <1472723464-22866-1-git-send-email-mhocko@kernel.org> <1472723464-22866-4-git-send-email-mhocko@kernel.org> <201609041050.BFG65134.OHVFQJOOSLMtFF@I-love.SAKURA.ne.jp> <20160909140851.GP4844@dhcp22.suse.cz> <201609101529.GCI12481.VOtOLHJQFOSMFF@I-love.SAKURA.ne.jp> <201609102155.AHJ57859.SOFHQFOtOFLJVM@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201609102155.AHJ57859.SOFHQFOtOFLJVM@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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