Michal Hocko wrote:
> On Fri 22-09-17 17:57:26, Tetsuo Handa wrote:
> [...]
> > Michal Hocko has nacked this patch [3], and he suggested an alternative
> > patch [4]. But he himself is not ready to clarify all the concerns with
> > the alternative patch [5]. In addition to that, nobody is interested in
> > either patch; we can not make progress here. Let's choose this patch for
> > now, for this patch has smaller impact than the alternative patch.
>
> My Nack stands and it is really annoying you are sending a patch for
> inclusion regardless of that fact. An alternative approach has been
> proposed and the mere fact that I do not have time to pursue this
> direction is not reason to go with a incomplete solution. This is not an
> issue many people would be facing to scream for a quick and dirty
> workarounds AFAIK (there have been 0 reports from non-artificial
> workloads).
>
But the alternative approach is also an incomplete solution because of below
limitations.
(1) Since we cannot use direct reclaim for this allocation attempt due to
oom_lock already held, an OOM victim will be prematurely killed which
could have been avoided if direct reclaim with oom_lock released was
used.
(2) Since we call panic() before calling oom_kill_process() when there is
no killable process, panic() will be prematurely called which could
have been avoided if this patch is used. For example, if a multithreaded
application running with a dedicated CPUs/memory was OOM-killed, we
can wait until ALLOC_OOM allocation fails to solve OOM situation.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
