From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: hannes@cmpxchg.org, akpm@linux-foundation.org, guro@fb.com, vdavydov.dev@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF Date: Mon, 12 Jun 2017 13:06:13 +0200 [thread overview] Message-ID: <20170612110612.GG7476@dhcp22.suse.cz> (raw) In-Reply-To: <201706121948.CEC81794.OFMLFSJOtHOQFV@I-love.SAKURA.ne.jp> 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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: hannes@cmpxchg.org, akpm@linux-foundation.org, guro@fb.com, vdavydov.dev@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF Date: Mon, 12 Jun 2017 13:06:13 +0200 [thread overview] Message-ID: <20170612110612.GG7476@dhcp22.suse.cz> (raw) In-Reply-To: <201706121948.CEC81794.OFMLFSJOtHOQFV@I-love.SAKURA.ne.jp> 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-06-12 11:06 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-19 11:26 [PATCH 0/2] fix premature OOM killer Michal Hocko 2017-05-19 11:26 ` Michal Hocko 2017-05-19 11:26 ` [PATCH 1/2] mm, oom: make sure that the oom victim uses memory reserves Michal Hocko 2017-05-19 11:26 ` Michal Hocko 2017-05-19 12:12 ` Tetsuo Handa 2017-05-19 12:12 ` Tetsuo Handa 2017-05-19 12:46 ` Michal Hocko 2017-05-19 12:46 ` Michal Hocko 2017-05-22 15:06 ` Roman Gushchin 2017-05-22 15:06 ` Roman Gushchin 2017-05-19 11:26 ` [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF Michal Hocko 2017-05-19 11:26 ` Michal Hocko 2017-05-19 13:02 ` Tetsuo Handa 2017-05-19 13:02 ` Tetsuo Handa 2017-05-19 13:22 ` Michal Hocko 2017-05-19 13:22 ` Michal Hocko 2017-05-19 15:22 ` Tetsuo Handa 2017-05-19 15:22 ` Tetsuo Handa 2017-05-19 15:50 ` Michal Hocko 2017-05-19 15:50 ` Michal Hocko 2017-05-19 23:43 ` Tetsuo Handa 2017-05-19 23:43 ` Tetsuo Handa 2017-05-22 9:31 ` Michal Hocko 2017-05-22 9:31 ` Michal Hocko 2017-06-08 14:36 ` Michal Hocko 2017-06-08 14:36 ` Michal Hocko 2017-06-09 14:08 ` Johannes Weiner 2017-06-09 14:08 ` Johannes Weiner 2017-06-09 14:46 ` Michal Hocko 2017-06-09 14:46 ` Michal Hocko 2017-06-10 8:49 ` Michal Hocko 2017-06-10 8:49 ` Michal Hocko 2017-06-10 11:57 ` [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the#PF Tetsuo Handa 2017-06-10 11:57 ` Tetsuo Handa 2017-06-12 7:39 ` Michal Hocko 2017-06-12 7:39 ` Michal Hocko 2017-06-12 10:48 ` [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF Tetsuo Handa 2017-06-12 10:48 ` Tetsuo Handa 2017-06-12 11:06 ` Michal Hocko [this message] 2017-06-12 11:06 ` Michal Hocko 2017-06-23 12:50 ` Michal Hocko 2017-06-23 12:50 ` Michal Hocko 2017-05-19 11:37 ` [PATCH 0/2] fix premature OOM killer Tetsuo Handa 2017-05-19 11:37 ` Tetsuo Handa 2017-05-19 12:47 ` Michal Hocko 2017-05-19 12:47 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170612110612.GG7476@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=vdavydov.dev@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.