linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
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
Date: Tue, 13 Sep 2016 09:21:11 +0200	[thread overview]
Message-ID: <20160913072111.GD31898@dhcp22.suse.cz> (raw)
In-Reply-To: <201609131525.IGF78600.JFOOVQMOLSHFFt@I-love.SAKURA.ne.jp>

On Tue 13-09-16 15:25:51, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Sat 10-09-16 21:55:49, Tetsuo Handa wrote:
> > > Tetsuo Handa wrote:
> > > > 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.
> 
> My intention is to somehow get rid of oom_killer_disable(). While I wrote
> this approach, I again came to wonder why we need to disable the OOM killer
> during suspend.
> 
> If the reason is that the OOM killer thaws already frozen OOM victims,
> we won't have reason to disable the OOM killer if the OOM killer does not
> thaw OOM victims. We can rely on the OOM killer/reaper immediately before
> start taking a memory snapshot for suspend.

Yes, if we don't have to wake already frozen tasks then the life would
be easier. But as I've already mentioned the async oom doesn't cover all
we need and the tasks can be frozen also from the userspace which means
that this is under user control.

> If the reason is that the OOM killer changes SIGKILL pending state of
> already frozen OOM victims during taking a memory snapshot, I think that
> sending SIGKILL via not only SysRq-f but also SysRq-i will be problematic.

Sysrq+i will not be a problem because that will not thaw any frozen
tasks.

> If the reason is that the OOM reaper changes content of mm_struct of
> OOM victims during taking a memory snapshot,

I do not think this is a problem. But I have to think about this some
more. My thinking is that even if saved the original content before
reaping it then all that matters is that the victim just goes away so it
cannot observe the corruption.

-- 
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>

  reply	other threads:[~2016-09-13  7:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01  9:51 [RFC 0/4] mm, oom: get rid of TIF_MEMDIE Michal Hocko
2016-09-01  9:51 ` [RFC 1/4] mm, oom: do not rely on TIF_MEMDIE for memory reserves access Michal Hocko
2016-09-04  1:49   ` Tetsuo Handa
2016-09-09 14:00     ` Michal Hocko
2016-09-01  9:51 ` [RFC 2/4] mm: replace TIF_MEMDIE checks by tsk_is_oom_victim Michal Hocko
2016-09-04  1:49   ` Tetsuo Handa
2016-09-09 14:05     ` Michal Hocko
2016-09-01  9:51 ` [RFC 3/4] mm, oom: do not rely on TIF_MEMDIE for exit_oom_victim Michal Hocko
2016-09-04  1:50   ` Tetsuo Handa
2016-09-09 14:08     ` Michal Hocko
2016-09-10  6:29       ` Tetsuo Handa
2016-09-10 12:55         ` Tetsuo Handa
2016-09-12  9:11           ` Michal Hocko
2016-09-13  6:25             ` Tetsuo Handa
2016-09-13  7:21               ` Michal Hocko [this message]
2016-09-14 13:50   ` Michal Hocko
2016-09-01  9:51 ` [RFC 4/4] arch: get rid of TIF_MEMDIE Michal Hocko
2016-09-15 14:41 ` [RFC 0/4] mm, oom: " Johannes Weiner
2016-09-16  7:15   ` Michal Hocko
2016-09-19 16:18     ` Johannes Weiner
2016-09-19 19:02       ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160913072111.GD31898@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).