From: Michal Hocko <mhocko@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, David Rientjes <rientjes@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Hugh Dickins <hughd@google.com>, Andrea Argangeli <andrea@kernel.org>, Rik van Riel <riel@redhat.com>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper Date: Fri, 18 Dec 2015 13:11:13 +0100 [thread overview] Message-ID: <20151218121112.GF28443@dhcp22.suse.cz> (raw) In-Reply-To: <20151217131356.83d920b7c250a785aa132139@linux-foundation.org> On Thu 17-12-15 13:13:56, Andrew Morton wrote: [...] > Also, re-reading your description: > > : It has been shown (e.g. by Tetsuo Handa) that it is not that hard to > : construct workloads which break the core assumption mentioned above and > : the OOM victim might take unbounded amount of time to exit because it > : might be blocked in the uninterruptible state waiting for on an event > : (e.g. lock) which is blocked by another task looping in the page > : allocator. > > So the allocating task has done an oom-kill and is waiting for memory > to become available. The killed task is stuck on some lock, unable to > free memory. > > But the problematic lock will sometimes be the killed tasks's mmap_sem, > so the reaper won't reap anything. This scenario requires that the > mmap_sem is held for writing, which sounds like it will be uncommon. Yes, I have mentioned that in the changelog: " oom_reaper has to take mmap_sem on the target task for reading so the solution is not 100% because the semaphore might be held or blocked for write but the probability is reduced considerably wrt. basically any lock blocking forward progress as described above. " Another thing is to do is to change down_write(mmap_sem) to down_write_killable in most cases where we have a clear ENITR semantic. This is on my todo list. > hm. sigh. I hate the oom-killer. Just buy some more memory already! Tell me something about that... -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, David Rientjes <rientjes@google.com>, Linus Torvalds <torvalds@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Hugh Dickins <hughd@google.com>, Andrea Argangeli <andrea@kernel.org>, Rik van Riel <riel@redhat.com>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper Date: Fri, 18 Dec 2015 13:11:13 +0100 [thread overview] Message-ID: <20151218121112.GF28443@dhcp22.suse.cz> (raw) In-Reply-To: <20151217131356.83d920b7c250a785aa132139@linux-foundation.org> On Thu 17-12-15 13:13:56, Andrew Morton wrote: [...] > Also, re-reading your description: > > : It has been shown (e.g. by Tetsuo Handa) that it is not that hard to > : construct workloads which break the core assumption mentioned above and > : the OOM victim might take unbounded amount of time to exit because it > : might be blocked in the uninterruptible state waiting for on an event > : (e.g. lock) which is blocked by another task looping in the page > : allocator. > > So the allocating task has done an oom-kill and is waiting for memory > to become available. The killed task is stuck on some lock, unable to > free memory. > > But the problematic lock will sometimes be the killed tasks's mmap_sem, > so the reaper won't reap anything. This scenario requires that the > mmap_sem is held for writing, which sounds like it will be uncommon. Yes, I have mentioned that in the changelog: " oom_reaper has to take mmap_sem on the target task for reading so the solution is not 100% because the semaphore might be held or blocked for write but the probability is reduced considerably wrt. basically any lock blocking forward progress as described above. " Another thing is to do is to change down_write(mmap_sem) to down_write_killable in most cases where we have a clear ENITR semantic. This is on my todo list. > hm. sigh. I hate the oom-killer. Just buy some more memory already! Tell me something about that... -- 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:[~2015-12-18 12:11 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-15 18:36 [PATCH 1/2] mm, oom: introduce oom reaper Michal Hocko 2015-12-15 18:36 ` Michal Hocko 2015-12-17 0:50 ` Andrew Morton 2015-12-17 0:50 ` Andrew Morton 2015-12-17 13:02 ` Michal Hocko 2015-12-17 13:02 ` Michal Hocko 2015-12-17 19:55 ` Linus Torvalds 2015-12-17 19:55 ` Linus Torvalds 2015-12-17 20:00 ` Andrew Morton 2015-12-17 20:00 ` Andrew Morton 2015-12-18 11:54 ` Michal Hocko 2015-12-18 11:54 ` Michal Hocko 2015-12-18 21:14 ` Andrew Morton 2015-12-18 21:14 ` Andrew Morton 2015-12-21 8:38 ` Michal Hocko 2015-12-21 8:38 ` Michal Hocko 2015-12-17 21:13 ` Andrew Morton 2015-12-17 21:13 ` Andrew Morton 2015-12-18 12:11 ` Michal Hocko [this message] 2015-12-18 12:11 ` Michal Hocko 2015-12-18 12:10 ` Tetsuo Handa 2015-12-18 12:10 ` Tetsuo Handa 2015-12-20 7:14 ` Tetsuo Handa 2015-12-20 7:14 ` Tetsuo Handa 2015-12-18 0:15 ` Andrew Morton 2015-12-18 0:15 ` Andrew Morton 2015-12-18 11:48 ` Michal Hocko 2015-12-18 11:48 ` Michal Hocko 2015-12-21 20:38 ` Paul Gortmaker 2015-12-21 20:38 ` Paul Gortmaker 2016-01-06 9:10 ` Michal Hocko 2016-01-06 9:10 ` Michal Hocko 2016-01-06 14:26 ` Paul Gortmaker 2016-01-06 14:26 ` Paul Gortmaker 2016-01-06 15:00 ` Michal Hocko 2016-01-06 15:00 ` Michal Hocko 2015-12-23 23:00 ` Ross Zwisler 2015-12-23 23:00 ` Ross Zwisler 2015-12-24 9:47 ` Michal Hocko 2015-12-24 9:47 ` Michal Hocko 2015-12-24 11:06 ` Tetsuo Handa 2015-12-24 11:06 ` Tetsuo Handa 2015-12-24 20:39 ` Ross Zwisler 2015-12-24 20:39 ` Ross Zwisler 2015-12-25 11:41 ` Michal Hocko 2015-12-25 11:41 ` Michal Hocko 2015-12-24 20:44 ` Ross Zwisler 2015-12-24 20:44 ` Ross Zwisler 2015-12-25 11:35 ` Michal Hocko 2015-12-25 11:35 ` Michal Hocko 2015-12-25 11:44 ` Michal Hocko 2015-12-25 11:44 ` Michal Hocko 2016-01-06 15:42 [PATCH 0/2 -mm] oom reaper v4 Michal Hocko 2016-01-06 15:42 ` [PATCH 1/2] mm, oom: introduce oom reaper Michal Hocko 2016-01-06 15:42 ` Michal Hocko 2016-01-07 11:23 ` Tetsuo Handa 2016-01-07 11:23 ` Tetsuo Handa 2016-01-07 12:30 ` Michal Hocko 2016-01-07 12:30 ` Michal Hocko 2016-01-11 22:54 ` Andrew Morton 2016-01-11 22:54 ` Andrew Morton 2016-01-12 8:16 ` Michal Hocko 2016-01-12 8:16 ` Michal Hocko 2016-01-28 1:28 ` David Rientjes 2016-01-28 1:28 ` David Rientjes 2016-01-28 21:42 ` Michal Hocko 2016-01-28 21:42 ` Michal Hocko 2016-02-02 3:02 ` David Rientjes 2016-02-02 3:02 ` David Rientjes 2016-02-02 8:57 ` Michal Hocko 2016-02-02 8:57 ` Michal Hocko 2016-02-02 11:48 ` Tetsuo Handa 2016-02-02 11:48 ` Tetsuo Handa 2016-02-02 22:55 ` David Rientjes 2016-02-02 22:55 ` David Rientjes 2016-02-02 22:51 ` David Rientjes 2016-02-02 22:51 ` David Rientjes 2016-02-03 10:31 ` Tetsuo Handa 2016-02-03 10:31 ` Tetsuo Handa
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=20151218121112.GF28443@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=andrea@kernel.org \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=oleg@redhat.com \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ --cc=torvalds@linux-foundation.org \ /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.