Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

From	Michal Hocko <mhocko@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF
Date	2017-06-12 13:10 +0200
Message-ID	<tRvol-1nx-13@gated-at.bofh.it> (permalink)
References	(1 earlier) <tQtoB-2MZ-11@gated-at.bofh.it> <tQKfM-4Nt-19@gated-at.bofh.it> <tQNdD-6xF-5@gated-at.bofh.it> <tRs77-7DQ-7@gated-at.bofh.it> <tRv4Z-10f-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Mon 12-06-17 19:48:03, Tetsuo Handa wrote:
> Michal Hocko wrote:
[...]
> >                                                       Without this patch
> > this would be impossible.
> 
> What I wanted to say is that, with this patch, you are introducing possibility
> of lockup. "Retrying the whole page fault path when page fault allocations
> failed but the OOM killer does not trigger" helps nothing. It will just spin
> wasting CPU time until somebody else invokes the OOM killer.

But this is very same with what we do in the page allocator already. We
keep retrying relying on somebody else making a forward progress on our
behalf for those requests which in a weaker reclaim context. So what
would be a _new_ lockup that didn't exist with the current code?
As I've already said (and I haven't heard a counter argument yet)
unwinding to the PF has a nice advantage that the whole locking context
will be gone as well. So unlike in the page allocator we can allow
others to make a forward progress. This sounds like an advantage to me.

The only possibility for a new lockup I can see is that some PF callpath
returned VM_FAULT_OOM without doing an actual allocation (aka leaked
VM_FAULT_OOM) and in that case it is a bug in that call path. Why should
we trigger a _global_ disruption action when the bug is specific to a
particular process? Moreover the global OOM killer will only stop this
path to refault by killing it which can happen after quite some other
processes being killed.
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the  #PF Michal Hocko <mhocko@kernel.org> - 2017-06-08 16:40 +0200
  Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the  #PF Johannes Weiner <hannes@cmpxchg.org> - 2017-06-09 16:10 +0200
    Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the  #PF Michal Hocko <mhocko@kernel.org> - 2017-06-09 16:50 +0200
      Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the  #PF Michal Hocko <mhocko@kernel.org> - 2017-06-10 10:50 +0200
        Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the#PF Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-10 14:00 +0200
          Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the#PF Michal Hocko <mhocko@kernel.org> - 2017-06-12 09:40 +0200
            Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-06-12 12:50 +0200
              Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the  #PF Michal Hocko <mhocko@kernel.org> - 2017-06-12 13:10 +0200

csiph-web