[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1804241256000.231037@chino.kir.corp.google.com>
Date: Tue, 24 Apr 2018 13:01:03 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Andrea Arcangeli <aarcange@...hat.com>, guro@...com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap
On Tue, 24 Apr 2018, Michal Hocko wrote:
> Is there any reason why we cannot simply call __oom_reap_task_mm as we
> have it now? mmap_sem for read shouldn't fail here because this is the
> last reference of the mm and we are past the ksm and khugepaged
> synchronizations. So unless my jed laged brain fools me the patch should
> be as simple as the following (I haven't tested it at all).
>
I wanted to remove all per task checks because they are now irrelevant:
this would be the first dependency that exit_mmap() has on any
task_struct, which isn't intuitive -- we simply want to exit the mmap.
There's no requirement that current owns the mm other than this. I wanted
to avoid the implicit dependency on MMF_OOM_SKIP and make it explicit in
the exit path to be matched with the oom reaper. I didn't want anything
additional printed to the kernel log about oom reaping unless the
oom_reaper actually needed to intervene, which is useful knowledge outside
of basic exiting.
My patch has passed intensive testing on both x86 and powerpc, so I'll ask
that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the suggestion
on calling __oom_reap_task_mm() from exit_mmap().
Powered by blists - more mailing lists