From: Michal Hocko <mhocko@kernel.org> To: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Rik van Riel <riel@redhat.com>, David Rientjes <rientjes@google.com>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [RFC 1/3] mm, oom: refactor oom detection Date: Fri, 30 Oct 2015 11:18:20 +0100 [thread overview] Message-ID: <20151030101819.GI18429@dhcp22.suse.cz> (raw) In-Reply-To: <56333B4A.4030602@jp.fujitsu.com> On Fri 30-10-15 18:41:30, KAMEZAWA Hiroyuki wrote: [...] > >>So, now, 0-order page allocation may fail in a OOM situation ? > > > >No they don't normally and this patch doesn't change the logic here. > > > > I understand your patch doesn't change the behavior. > Looking into __alloc_pages_may_oom(), *did_some_progress is finally set by > > if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) > *did_some_progress = 1; > > ...depends on out_of_memory() return value. > Now, allocation may fail if oom-killer is disabled.... Isn't it complicated ? Yes and there shouldn't be any allocations after OOM killer has been disabled. The userspace is already frozen and there shouldn't be any other memory activity. > Shouldn't we have > > if (order < PAGE_ALLOC_COSTLY_ORDER) > goto retry; > > here ? How could we move on during the suspend if the reclaim doesn't proceed and we cannot really kill anything to free up memory resources. We are simply past the moment any userspace can be woken up. Anyway this is tangent to this particular patch series. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Mel Gorman <mgorman@suse.de>, Johannes Weiner <hannes@cmpxchg.org>, Rik van Riel <riel@redhat.com>, David Rientjes <rientjes@google.com>, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [RFC 1/3] mm, oom: refactor oom detection Date: Fri, 30 Oct 2015 11:18:20 +0100 [thread overview] Message-ID: <20151030101819.GI18429@dhcp22.suse.cz> (raw) In-Reply-To: <56333B4A.4030602@jp.fujitsu.com> On Fri 30-10-15 18:41:30, KAMEZAWA Hiroyuki wrote: [...] > >>So, now, 0-order page allocation may fail in a OOM situation ? > > > >No they don't normally and this patch doesn't change the logic here. > > > > I understand your patch doesn't change the behavior. > Looking into __alloc_pages_may_oom(), *did_some_progress is finally set by > > if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) > *did_some_progress = 1; > > ...depends on out_of_memory() return value. > Now, allocation may fail if oom-killer is disabled.... Isn't it complicated ? Yes and there shouldn't be any allocations after OOM killer has been disabled. The userspace is already frozen and there shouldn't be any other memory activity. > Shouldn't we have > > if (order < PAGE_ALLOC_COSTLY_ORDER) > goto retry; > > here ? How could we move on during the suspend if the reclaim doesn't proceed and we cannot really kill anything to free up memory resources. We are simply past the moment any userspace can be woken up. Anyway this is tangent to this particular patch series. -- 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-10-30 10:18 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-29 15:17 RFC: OOM detection rework v1 mhocko 2015-10-29 15:17 ` mhocko 2015-10-29 15:17 ` [RFC 1/3] mm, oom: refactor oom detection mhocko 2015-10-29 15:17 ` mhocko 2015-10-30 4:10 ` Hillf Danton 2015-10-30 4:10 ` Hillf Danton 2015-10-30 8:36 ` Michal Hocko 2015-10-30 8:36 ` Michal Hocko 2015-10-30 10:14 ` Michal Hocko 2015-10-30 10:14 ` Michal Hocko 2015-10-30 13:32 ` Tetsuo Handa 2015-10-30 13:32 ` Tetsuo Handa 2015-10-30 14:55 ` Michal Hocko 2015-10-30 14:55 ` Michal Hocko 2015-10-31 3:57 ` Hillf Danton 2015-10-31 3:57 ` Hillf Danton 2015-10-30 5:23 ` Kamezawa Hiroyuki 2015-10-30 5:23 ` Kamezawa Hiroyuki 2015-10-30 8:23 ` Michal Hocko 2015-10-30 8:23 ` Michal Hocko 2015-10-30 9:41 ` Kamezawa Hiroyuki 2015-10-30 9:41 ` Kamezawa Hiroyuki 2015-10-30 10:18 ` Michal Hocko [this message] 2015-10-30 10:18 ` Michal Hocko 2015-11-12 12:39 ` Michal Hocko 2015-11-12 12:39 ` Michal Hocko 2015-10-29 15:17 ` [RFC 2/3] mm: throttle on IO only when there are too many dirty and writeback pages mhocko 2015-10-29 15:17 ` mhocko 2015-10-30 4:18 ` Hillf Danton 2015-10-30 4:18 ` Hillf Danton 2015-10-30 8:37 ` Michal Hocko 2015-10-30 8:37 ` Michal Hocko 2015-10-30 5:48 ` Kamezawa Hiroyuki 2015-10-30 5:48 ` Kamezawa Hiroyuki 2015-10-30 8:38 ` Michal Hocko 2015-10-30 8:38 ` Michal Hocko 2015-10-29 15:17 ` [RFC 3/3] mm: use watermak checks for __GFP_REPEAT high order allocations mhocko 2015-10-29 15:17 ` mhocko 2015-11-12 12:44 ` RFC: OOM detection rework v1 Michal Hocko 2015-11-12 12:44 ` Michal Hocko 2015-11-18 13:03 [RFC 0/3] OOM detection rework v2 Michal Hocko 2015-11-18 13:03 ` [RFC 1/3] mm, oom: refactor oom detection Michal Hocko 2015-11-19 23:01 ` David Rientjes 2015-11-20 9:06 ` Michal Hocko 2015-11-20 23:27 ` David Rientjes 2015-11-23 9:41 ` Michal Hocko 2015-11-23 18:24 ` Johannes Weiner 2015-11-24 10:03 ` Michal Hocko 2015-12-01 12:56 [RFC 0/3] OOM detection rework v3 Michal Hocko 2015-12-01 12:56 ` [RFC 1/3] mm, oom: refactor oom detection Michal Hocko 2015-12-11 16:16 ` Johannes Weiner 2015-12-14 18:34 ` 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=20151030101819.GI18429@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --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.