From: Michal Hocko <mhocko@kernel.org> To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: hillf.zj@alibaba-inc.com, linux-mm@kvack.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, mgorman@suse.de, hannes@cmpxchg.org, riel@redhat.com, rientjes@google.com, linux-kernel@vger.kernel.org Subject: Re: [RFC 1/3] mm, oom: refactor oom detection Date: Fri, 30 Oct 2015 15:55:39 +0100 [thread overview] Message-ID: <20151030145539.GF23627@dhcp22.suse.cz> (raw) In-Reply-To: <201510302232.FCH52626.OQJOFHSVFFOtLM@I-love.SAKURA.ne.jp> On Fri 30-10-15 22:32:27, Tetsuo Handa wrote: > Michal Hocko wrote: > > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / MAX_STALL_BACKOFF; > target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); Ohh, we have a macro for that. Good to know. Thanks. It sure looks much easier to follow. > Michal Hocko wrote: > > This alone wouldn't be sufficient, though, because the writeback might > > get stuck and reclaimable pages might be pinned for a really long time > > or even depend on the current allocation context. > > Is this a dependency which I worried at > http://lkml.kernel.org/r/201510262044.BAI43236.FOMSFFOtOVLJQH@I-love.SAKURA.ne.jp ? Yes, I had restricted allocation contexts in mind here. > > Therefore there is a > > feedback mechanism implemented which reduces the reclaim target after > > each reclaim round without any progress. > > If yes, this feedback mechanism will help avoiding infinite wait loop. > > > This means that we should > > eventually converge to only NR_FREE_PAGES as the target and fail on the > > wmark check and proceed to OOM. > > What if all in-flight allocation requests are !__GFP_NOFAIL && !__GFP_FS ? Then we will loop like crazy hoping that _something_ will reclaim memory for us. Same as we do now. > (In other words, either "no __GFP_FS allocations are in-flight" or "all > __GFP_FS allocations are in-flight but are either waiting for completion > of operations which depend on !__GFP_FS allocations with a lock held or > waiting for that lock to be released".) > > Don't we need to call out_of_memory() even though !__GFP_FS allocations? I do not think this is in scope of this patch series. I am trying to normalize the OOM detection and GFP_FS is a separate beast and we do not have enough counters to decide the whether OOM killer would be premature or not (e.g. we do not know how much memory is unreclaimable just because of NOFS context). I am convinced that GFP_FS simply has to fail the allocation as I've suggested quite some time ago and plan to revisit it soon(ish). I consider the two orthogonal. Thanks! -- 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: hillf.zj@alibaba-inc.com, linux-mm@kvack.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, mgorman@suse.de, hannes@cmpxchg.org, riel@redhat.com, rientjes@google.com, linux-kernel@vger.kernel.org Subject: Re: [RFC 1/3] mm, oom: refactor oom detection Date: Fri, 30 Oct 2015 15:55:39 +0100 [thread overview] Message-ID: <20151030145539.GF23627@dhcp22.suse.cz> (raw) In-Reply-To: <201510302232.FCH52626.OQJOFHSVFFOtLM@I-love.SAKURA.ne.jp> On Fri 30-10-15 22:32:27, Tetsuo Handa wrote: > Michal Hocko wrote: > > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / MAX_STALL_BACKOFF; > target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); Ohh, we have a macro for that. Good to know. Thanks. It sure looks much easier to follow. > Michal Hocko wrote: > > This alone wouldn't be sufficient, though, because the writeback might > > get stuck and reclaimable pages might be pinned for a really long time > > or even depend on the current allocation context. > > Is this a dependency which I worried at > http://lkml.kernel.org/r/201510262044.BAI43236.FOMSFFOtOVLJQH@I-love.SAKURA.ne.jp ? Yes, I had restricted allocation contexts in mind here. > > Therefore there is a > > feedback mechanism implemented which reduces the reclaim target after > > each reclaim round without any progress. > > If yes, this feedback mechanism will help avoiding infinite wait loop. > > > This means that we should > > eventually converge to only NR_FREE_PAGES as the target and fail on the > > wmark check and proceed to OOM. > > What if all in-flight allocation requests are !__GFP_NOFAIL && !__GFP_FS ? Then we will loop like crazy hoping that _something_ will reclaim memory for us. Same as we do now. > (In other words, either "no __GFP_FS allocations are in-flight" or "all > __GFP_FS allocations are in-flight but are either waiting for completion > of operations which depend on !__GFP_FS allocations with a lock held or > waiting for that lock to be released".) > > Don't we need to call out_of_memory() even though !__GFP_FS allocations? I do not think this is in scope of this patch series. I am trying to normalize the OOM detection and GFP_FS is a separate beast and we do not have enough counters to decide the whether OOM killer would be premature or not (e.g. we do not know how much memory is unreclaimable just because of NOFS context). I am convinced that GFP_FS simply has to fail the allocation as I've suggested quite some time ago and plan to revisit it soon(ish). I consider the two orthogonal. Thanks! -- 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 14:55 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 [this message] 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 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=20151030145539.GF23627@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=hillf.zj@alibaba-inc.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.