From: Michal Hocko <mhocko@kernel.org> To: David Rientjes <rientjes@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [patch] mm, oom: prevent additional oom kills before memory is freed Date: Fri, 16 Jun 2017 10:06:21 +0200 [thread overview] Message-ID: <20170616080620.GB30580@dhcp22.suse.cz> (raw) In-Reply-To: <alpine.DEB.2.10.1706151534170.140219@chino.kir.corp.google.com> On Thu 15-06-17 15:42:23, David Rientjes wrote: > 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 am not aware of any specific bug report. But the main point of the reaper is to close all _possible_ lockups due to oom victim being stuck somewhere. exit_aio waits for all kiocbs. Can we guarantee that none of them will depend on an allocation (directly or via a lock chain) to proceed? Likewise ksm_exit/khugepaged_exit depend on mmap_sem for write to proceed. Are we _guaranteed_ nobody can hold mmap_sem for read at that time and depend on an allocation? Can we guarantee that __mmput path will work without any depency on allocation in future? > 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 am not questioning that it works for your particular test. I just argue that it reduces the robustness of the oom reaper because it allows oom victim to leave the reaper without MMF_OOM_SKIP set and that is the core concept to guarantee a forward progress. So we should think about something more appropriate. > 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. Well, __mmput path already depends on the mmap_sem for write. So this is not a new concept. I am not saying using mmap_sem is the only way. I will think about that more. > 4.12 needs to stop killing 2-5 processes on every oom condition instead of > 1. Believe me, I am not dismissing the issue nor the fact it _has_ to be fixed. I just disagree we should make the oom reaper less robust. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: David Rientjes <rientjes@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [patch] mm, oom: prevent additional oom kills before memory is freed Date: Fri, 16 Jun 2017 10:06:21 +0200 [thread overview] Message-ID: <20170616080620.GB30580@dhcp22.suse.cz> (raw) In-Reply-To: <alpine.DEB.2.10.1706151534170.140219@chino.kir.corp.google.com> On Thu 15-06-17 15:42:23, David Rientjes wrote: > 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 am not aware of any specific bug report. But the main point of the reaper is to close all _possible_ lockups due to oom victim being stuck somewhere. exit_aio waits for all kiocbs. Can we guarantee that none of them will depend on an allocation (directly or via a lock chain) to proceed? Likewise ksm_exit/khugepaged_exit depend on mmap_sem for write to proceed. Are we _guaranteed_ nobody can hold mmap_sem for read at that time and depend on an allocation? Can we guarantee that __mmput path will work without any depency on allocation in future? > 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 am not questioning that it works for your particular test. I just argue that it reduces the robustness of the oom reaper because it allows oom victim to leave the reaper without MMF_OOM_SKIP set and that is the core concept to guarantee a forward progress. So we should think about something more appropriate. > 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. Well, __mmput path already depends on the mmap_sem for write. So this is not a new concept. I am not saying using mmap_sem is the only way. I will think about that more. > 4.12 needs to stop killing 2-5 processes on every oom condition instead of > 1. Believe me, I am not dismissing the issue nor the fact it _has_ to be fixed. I just disagree we should make the oom reaper less robust. -- 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-16 8:06 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-14 23:43 [patch] mm, oom: prevent additional oom kills before memory is freed David Rientjes 2017-06-14 23:43 ` David Rientjes 2017-06-15 10:39 ` Michal Hocko 2017-06-15 10:39 ` Michal Hocko 2017-06-15 10:53 ` Tetsuo Handa 2017-06-15 10:53 ` Tetsuo Handa 2017-06-15 11:01 ` Michal Hocko 2017-06-15 11:01 ` Michal Hocko 2017-06-15 11:32 ` Tetsuo Handa 2017-06-15 11:32 ` Tetsuo Handa 2017-06-15 12:03 ` Michal Hocko 2017-06-15 12:03 ` Michal Hocko 2017-06-15 12:13 ` Michal Hocko 2017-06-15 12:13 ` Michal Hocko 2017-06-15 13:01 ` Tetsuo Handa 2017-06-15 13:01 ` Tetsuo Handa 2017-06-15 13:22 ` Michal Hocko 2017-06-15 13:22 ` Michal Hocko 2017-06-15 21:43 ` Tetsuo Handa 2017-06-15 21:43 ` Tetsuo Handa 2017-06-15 21:37 ` David Rientjes 2017-06-15 21:37 ` David Rientjes 2017-06-15 12:20 ` Michal Hocko 2017-06-15 12:20 ` Michal Hocko 2017-06-15 21:26 ` David Rientjes 2017-06-15 21:26 ` David Rientjes 2017-06-15 21:41 ` Michal Hocko 2017-06-15 21:41 ` Michal Hocko 2017-06-15 22:03 ` David Rientjes 2017-06-15 22:03 ` David Rientjes 2017-06-15 22:12 ` Michal Hocko 2017-06-15 22:12 ` Michal Hocko 2017-06-15 22:42 ` David Rientjes 2017-06-15 22:42 ` David Rientjes 2017-06-16 8:06 ` Michal Hocko [this message] 2017-06-16 8:06 ` Michal Hocko 2017-06-16 0:54 ` Tetsuo Handa 2017-06-16 0:54 ` Tetsuo Handa 2017-06-16 4:00 ` Tetsuo Handa 2017-06-16 4:00 ` Tetsuo Handa 2017-06-16 8:39 ` Michal Hocko 2017-06-16 8:39 ` Michal Hocko 2017-06-16 10:27 ` Tetsuo Handa 2017-06-16 10:27 ` Tetsuo Handa 2017-06-16 11:02 ` Michal Hocko 2017-06-16 11:02 ` Michal Hocko 2017-06-16 14:26 ` Re: [patch] mm, oom: prevent additional oom kills before memoryis freed Tetsuo Handa 2017-06-16 14:26 ` Tetsuo Handa 2017-06-16 14:42 ` Michal Hocko 2017-06-16 14:42 ` Michal Hocko 2017-06-17 13:30 ` Re: [patch] mm, oom: prevent additional oom kills before memory is freed Tetsuo Handa 2017-06-17 13:30 ` Tetsuo Handa 2017-06-23 12:38 ` Michal Hocko 2017-06-23 12:38 ` Michal Hocko 2017-06-16 12:22 ` Tetsuo Handa 2017-06-16 12:22 ` Tetsuo Handa 2017-06-16 14:12 ` Michal Hocko 2017-06-16 14:12 ` Michal Hocko 2017-06-17 5:17 ` [PATCH] mm,oom_kill: Close race window of needlessly selecting new victims Tetsuo Handa 2017-06-17 5:17 ` Tetsuo Handa 2017-06-20 22:12 ` David Rientjes 2017-06-20 22:12 ` David Rientjes 2017-06-21 2:17 ` Tetsuo Handa 2017-06-21 20:31 ` David Rientjes 2017-06-21 20:31 ` David Rientjes 2017-06-22 0:53 ` Tetsuo Handa 2017-06-23 12:45 ` Michal Hocko 2017-06-23 12:45 ` Michal Hocko 2017-06-21 13:18 ` Michal Hocko 2017-06-21 13:18 ` 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=20170616080620.GB30580@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=rientjes@google.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.