From: David Rientjes <rientjes@google.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Andrea Arcangeli <aarcange@redhat.com>,
Roman Gushchin <guro@fb.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap
Date: Sat, 21 Apr 2018 20:45:11 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.1804212023120.84222@chino.kir.corp.google.com> (raw)
In-Reply-To: <20180420082349.GW17484@dhcp22.suse.cz>
On Fri, 20 Apr 2018, Michal Hocko wrote:
> > The solution is certainly not to hold
> > down_write(&mm->mmap_sem) during munlock_vma_pages_all() instead.
>
> Why not? This is what we do for normal paths. exit path just tries to be
> clever because it knows that it doesn't have to lock because there is no
> concurent user. At least it wasn't until the oom reaper came. So I
> really fail to see why we shouldn't do the most obvious thing and use
> the locking.
>
Because the oom reaper uses the ability to acquire mm->mmap_sem as a
heuristic to determine when to give up and allow another process to be
chosen.
If the heuristics of the oom reaper are to be improved, that's great, but
this patch fixes the oops on powerpc as 4.17 material and as a stable
backport. It's also well tested.
> > If
> > exit_mmap() is not making forward progress then that's a separate issue;
>
> Please read what I wrote. There is a page lock and there is no way to
> guarantee it will make a forward progress. Or do you consider that not
> true?
>
I don't have any evidence of it, and since this is called before
exit_mmap() sets MMF_OOM_SKIP then the oom reaper would need to set the
bit itself and I would be able to find the artifact it leaves behind in
the kernel log. I cannot find a single instance of a thread stuck in
munlock by way of exit_mmap() that causes the oom reaper to have to set
the bit itself, and I should be able to if this were a problem.
> > Holding down_write on
> > mm->mmap_sem otherwise needlessly over a large amount of code is riskier
> > (hasn't been done or tested here), more error prone (any code change over
> > this large area of code or in functions it calls are unnecessarily
> > burdened by unnecessary locking), makes exit_mmap() less extensible for
> > the same reason,
>
> I do not see any of the calls in that path could suffer from holding
> mmap_sem. Do you?
>
> > and causes the oom reaper to give up and go set
> > MMF_OOM_SKIP itself because it depends on taking down_read while the
> > thread is still exiting.
>
> Which is the standard backoff mechanism.
>
The reason today's locking methodology is preferred is because of the
backoff mechanism. Your patch kills many processes unnecessarily if the
oom killer selects a large process to kill, which it specifically tries to
do, because unmap_vmas() and free_pgtables() takes a very long time,
sometimes tens of seconds.
next prev parent reply other threads:[~2018-04-22 3:45 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 22:46 [patch] mm, oom: fix concurrent munlock and oom reaper unmap David Rientjes
2018-04-18 0:57 ` Tetsuo Handa
2018-04-18 2:39 ` David Rientjes
2018-04-18 2:52 ` [patch v2] " David Rientjes
2018-04-18 3:55 ` Tetsuo Handa
2018-04-18 4:11 ` David Rientjes
2018-04-18 4:47 ` Tetsuo Handa
2018-04-18 5:20 ` David Rientjes
2018-04-18 7:50 ` Michal Hocko
2018-04-18 11:49 ` Tetsuo Handa
2018-04-18 11:58 ` Michal Hocko
2018-04-18 13:25 ` Tetsuo Handa
2018-04-18 13:44 ` Michal Hocko
2018-04-18 14:28 ` Tetsuo Handa
2018-04-18 19:14 ` David Rientjes
2018-04-19 6:35 ` Michal Hocko
2018-04-19 10:45 ` Tetsuo Handa
2018-04-19 11:04 ` Michal Hocko
2018-04-19 11:51 ` Tetsuo Handa
2018-04-19 12:48 ` Michal Hocko
2018-04-19 19:14 ` David Rientjes
2018-04-19 19:34 ` David Rientjes
2018-04-19 22:13 ` Tetsuo Handa
2018-04-20 8:23 ` Michal Hocko
2018-04-20 12:40 ` Michal Hocko
2018-04-20 12:40 ` Michal Hocko
2018-04-22 3:22 ` David Rientjes
2018-04-22 3:48 ` [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap Tetsuo Handa
2018-04-22 13:08 ` Michal Hocko
2018-04-24 2:31 ` David Rientjes
2018-04-24 5:11 ` Tetsuo Handa
2018-04-24 5:35 ` David Rientjes
2018-04-24 21:57 ` [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap Tetsuo Handa
2018-04-24 22:25 ` David Rientjes
2018-04-24 22:34 ` [patch v3 for-4.17] " David Rientjes
2018-04-24 23:19 ` Michal Hocko
2018-04-24 13:04 ` [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap Michal Hocko
2018-04-24 20:01 ` David Rientjes
2018-04-24 20:13 ` Michal Hocko
2018-04-24 20:22 ` David Rientjes
2018-04-24 20:31 ` Michal Hocko
2018-04-24 21:07 ` David Rientjes
2018-04-24 23:08 ` Michal Hocko
2018-04-24 23:14 ` Michal Hocko
2018-04-22 3:45 ` David Rientjes [this message]
2018-04-22 13:18 ` [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap Michal Hocko
2018-04-23 16:09 ` 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=alpine.DEB.2.21.1804212023120.84222@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.