[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1706151534170.140219@chino.kir.corp.google.com>
Date: Thu, 15 Jun 2017 15:42:23 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...nel.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] mm, oom: prevent additional oom kills before memory is
freed
On Fri, 16 Jun 2017, Michal Hocko wrote:
> I am sorry but I have really hard to make the oom reaper a reliable way
> to stop all the potential oom lockups go away. I do not want to
> reintroduce another potential lockup now.
Please show where this "potential lockup" ever existed in a bug report or
a testcase? I have never seen __mmput() block when trying to free the
memory it maps.
> I also do not see why any
> solution should be rushed into. I have proposed a way to go and unless
> it is clear that this is not a way forward then I simply do not agree
> with any partial workarounds or shortcuts.
This is not a shortcut, it is a bug fix. 4.12 kills 1-4 processes
unnecessarily as a result of setting MMF_OOM_SKIP incorrectly before the
mm's memory can be freed. If you have not seen this issue before, which
is why you asked if I ever observed it in practice, then you have not
stress tested oom reaping. It is very observable and reproducible. I do
not agree that adding additional and obscure locking into __mmput() is the
solution to what is plainly and obviously fixed with this simple patch.
4.12 needs to stop killing 2-5 processes on every oom condition instead of
1.
Powered by blists - more mailing lists