From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: mhocko@kernel.org 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 22:32:27 +0900 [thread overview] Message-ID: <201510302232.FCH52626.OQJOFHSVFFOtLM@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <20151030101436.GH18429@dhcp22.suse.cz> Michal Hocko wrote: > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / MAX_STALL_BACKOFF; target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); 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 ? > 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 ? (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? > The backoff is simple and linear with > 1/16 of the reclaimable pages for each round without any progress. We > are optimistic and reset counter for successful reclaim rounds.
WARNING: multiple messages have this Message-ID (diff)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: mhocko@kernel.org 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 22:32:27 +0900 [thread overview] Message-ID: <201510302232.FCH52626.OQJOFHSVFFOtLM@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <20151030101436.GH18429@dhcp22.suse.cz> Michal Hocko wrote: > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / MAX_STALL_BACKOFF; target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); 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 ? > 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 ? (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? > The backoff is simple and linear with > 1/16 of the reclaimable pages for each round without any progress. We > are optimistic and reset counter for successful reclaim rounds. -- 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 13:32 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 [this message] 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 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=201510302232.FCH52626.OQJOFHSVFFOtLM@I-love.SAKURA.ne.jp \ --to=penguin-kernel@i-love.sakura.ne.jp \ --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=mhocko@kernel.org \ --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.