From: Mel Gorman <email@example.com> To: Shakeel Butt <firstname.lastname@example.org> Cc: Andrew Morton <email@example.com>, Michal Hocko <firstname.lastname@example.org>, Vlastimil Babka <email@example.com>, Alexey Avramov <firstname.lastname@example.org>, Rik van Riel <email@example.com>, Mike Galbraith <firstname.lastname@example.org>, Darrick Wong <email@example.com>, firstname.lastname@example.org, Linux-fsdevel <email@example.com>, Linux-MM <firstname.lastname@example.org>, LKML <email@example.com> Subject: Re: [PATCH v4 1/1] mm: vmscan: Reduce throttling due to a failure to make progress Date: Tue, 7 Dec 2021 09:28:03 +0000 [thread overview] Message-ID: <20211207092803.GI3366@techsingularity.net> (raw) In-Reply-To: <CALvZod6NPzzD=rzvmgLNsudCDVNJWgwviijB1LztRAhCX7jQBA@mail.gmail.com> On Mon, Dec 06, 2021 at 11:14:58PM -0800, Shakeel Butt wrote: > On Mon, Dec 6, 2021 at 3:25 AM Mel Gorman <firstname.lastname@example.org> wrote: > > > > On Sun, Dec 05, 2021 at 10:06:27PM -0800, Shakeel Butt wrote: > > > On Fri, Dec 3, 2021 at 11:08 AM Mel Gorman <email@example.com> wrote: > > > > > > > [...] > > > > > I am in agreement with the motivation of the whole series. I am just > > > > > making sure that the motivation of VMSCAN_THROTTLE_NOPROGRESS based > > > > > throttle is more than just the congestion_wait of > > > > > mem_cgroup_force_empty_write. > > > > > > > > > > > > > The commit that primarily targets congestion_wait is 8cd7c588decf > > > > ("mm/vmscan: throttle reclaim until some writeback completes if > > > > congested"). The series recognises that there are other reasons why > > > > reclaim can fail to make progress that is not directly writeback related. > > > > > > > > > > I agree with throttling for VMSCAN_THROTTLE_[WRITEBACK|ISOLATED] > > > reasons. Please explain why we should throttle for > > > VMSCAN_THROTTLE_NOPROGRESS? Also 69392a403f49 claims "Direct reclaim > > > primarily is throttled in the page allocator if it is failing to make > > > progress.", can you please explain how? > > > > It could happen if the pages on the LRU are being reactivated continually > > or holding an elevated reference count for some reason (e.g. gup, > > page migration etc). The event is probably transient, hence the short > > throttling. > > > > What's the worst that can happen if the kernel doesn't throttle at all > for these transient scenarios? Premature oom-kills? Excessive CPU usage in reclaim, potential premature OOM kills. > The kernel already > has some protection against such situations with retries i.e. > consecutive 16 unsuccessful reclaim tries have to fail to give up the > reclaim. > The retries mitigate the premature OOM kills but not the excessive CPU usage. > Anyways, I have shared my view which is 'no need to throttle at all > for no-progress reclaims for now and course correct if there are > complaints in future' but will not block the patch. > We've gone through periods of bugs that had either direct reclaim or kswapd pegged at 100% CPU usage. While kswapd now just stops, the patch still minimises the risk of excessive CPU usage bugs due to direct reclaim. -- Mel Gorman SUSE Labs
next prev parent reply other threads:[~2021-12-07 9:28 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-02 15:06 Mel Gorman 2021-12-02 16:30 ` Shakeel Butt 2021-12-02 16:52 ` Mel Gorman 2021-12-02 17:41 ` Shakeel Butt 2021-12-03 9:01 ` Mel Gorman 2021-12-03 17:50 ` Shakeel Butt 2021-12-03 19:08 ` Mel Gorman 2021-12-06 6:06 ` Shakeel Butt 2021-12-06 11:25 ` Mel Gorman 2021-12-07 7:14 ` Shakeel Butt 2021-12-07 9:28 ` Mel Gorman [this message] 2021-12-09 6:20 ` Hugh Dickins 2021-12-09 9:53 ` Mel Gorman 2021-12-28 10:04 ` Thorsten Leemhuis 2021-12-29 23:45 ` Andrew Morton 2021-12-31 14:24 ` Thorsten Leemhuis 2021-12-31 18:33 ` Hugh Dickins 2021-12-31 19:14 ` Linus Torvalds 2021-12-31 19:21 ` Linus Torvalds 2021-12-31 19:22 ` Linus Torvalds 2022-01-01 10:52 ` Thorsten Leemhuis 2021-12-31 21:04 ` Andrew Morton 2021-12-31 21:18 ` Linus Torvalds 2022-02-14 21:10 ` Shuang Zhai 2022-02-15 14:49 ` Mel Gorman 2022-02-22 17:27 ` [PATCH v4 1/1] mm: vmscan: Reduce throttling due to a failure to make progress' Shuang Zhai 2022-02-23 12:50 ` Mel Gorman
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=20211207092803.GI3366@techsingularity.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v4 1/1] mm: vmscan: Reduce throttling due to a failure to make progress' \ /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: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).