[lkml]   [2018]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap
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

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.

 \ /
  Last update: 2018-04-22 05:45    [W:0.131 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site