From: Michal Hocko <mhocko@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: linux-mm@kvack.org,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Oleg Nesterov <oleg@redhat.com>,
Andrea Argangeli <andrea@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap
Date: Wed, 12 Jul 2017 09:12:41 +0200 [thread overview]
Message-ID: <20170712071241.GA28912@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.10.1707111336250.60183@chino.kir.corp.google.com>
On Tue 11-07-17 13:40:04, David Rientjes wrote:
> On Tue, 11 Jul 2017, Michal Hocko wrote:
>
> > This?
> > ---
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 5dc0ff22d567..e155d1d8064f 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -470,11 +470,14 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
> > {
> > struct mmu_gather tlb;
> > struct vm_area_struct *vma;
> > - bool ret = true;
> >
> > if (!down_read_trylock(&mm->mmap_sem))
> > return false;
> >
> > + /* There is nothing to reap so bail out without signs in the log */
> > + if (!mm->mmap)
> > + goto unlock;
> > +
> > /*
> > * Tell all users of get_user/copy_from_user etc... that the content
> > * is no longer stable. No barriers really needed because unmapping
> > @@ -508,9 +511,10 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
> > K(get_mm_counter(mm, MM_ANONPAGES)),
> > K(get_mm_counter(mm, MM_FILEPAGES)),
> > K(get_mm_counter(mm, MM_SHMEMPAGES)));
> > +unlock:
> > up_read(&mm->mmap_sem);
> >
> > - return ret;
> > + return true;
> > }
> >
> > #define MAX_OOM_REAP_RETRIES 10
>
> Yes, this folded in with the original RFC patch appears to work better
> with light testing.
Yes folding it into the original patch was the plan. I would really
appreciate some Tested-by here.
> However, I think MAX_OOM_REAP_RETRIES and/or the timeout of HZ/10 needs to
> be increased as well to address the issue that Tetsuo pointed out. The
> oom reaper shouldn't be required to do any work unless it is resolving a
> livelock, and that scenario should be relatively rare. The oom killer
> being a natural ultra slow path, I think it would be justifiable to wait
> longer or retry more times than simply 1 second before declaring that
> reaping is not possible. It reduces the likelihood of additional oom
> killing.
I believe that this is an independent issue and as such it should be
addressed separately along with some data backing up that decision. I am
not against improving the waiting logic. We would need some requeuing
when we cannot reap the victim because we cannot really wait too much
time on a single oom victim considering there might be many victims
queued (because of memcg ooms). This would obviously need some more code
and I am willing to implement that but I would like to see that this is
something that is a real problem first.
Thanks!
--
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>
prev parent reply other threads:[~2017-07-12 7:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-26 13:03 [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap Michal Hocko
2017-06-27 10:52 ` Tetsuo Handa
2017-06-27 11:26 ` Michal Hocko
2017-06-27 11:39 ` Tetsuo Handa
2017-06-27 12:03 ` Michal Hocko
2017-06-27 13:31 ` Tetsuo Handa
2017-06-27 13:55 ` Michal Hocko
2017-06-27 14:26 ` Tetsuo Handa
2017-06-27 14:41 ` Michal Hocko
2017-07-11 0:01 ` David Rientjes
2017-06-29 8:46 ` Michal Hocko
2017-07-19 5:55 ` Michal Hocko
2017-07-20 1:18 ` Hugh Dickins
2017-07-20 13:05 ` Michal Hocko
2017-07-24 6:39 ` Hugh Dickins
2017-07-10 23:55 ` David Rientjes
2017-07-11 6:58 ` Michal Hocko
2017-07-11 20:40 ` David Rientjes
2017-07-12 7:12 ` Michal Hocko [this message]
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=20170712071241.GA28912@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrea@kernel.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 \
/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).