From: Hugh Dickins <email@example.com> To: Andrew Morton <firstname.lastname@example.org> Cc: Thorsten Leemhuis <email@example.com>, Mel Gorman <firstname.lastname@example.org>, Mark Brown <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>, Linus Torvalds <firstname.lastname@example.org> Subject: Re: [PATCH v4 1/1] mm: vmscan: Reduce throttling due to a failure to make progress Date: Fri, 31 Dec 2021 10:33:55 -0800 (PST) [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, 31 Dec 2021, Thorsten Leemhuis wrote: > On 30.12.21 00:45, Andrew Morton wrote: > > On Tue, 28 Dec 2021 11:04:18 +0100 Thorsten Leemhuis <email@example.com> wrote: > > > >> Hi, this is your Linux kernel regression tracker speaking. > >> > >> On 02.12.21 16:06, Mel Gorman wrote: > >>> Mike Galbraith, Alexey Avramov and Darrick Wong all reported similar > >>> problems due to reclaim throttling for excessive lengths of time. > >>> In Alexey's case, a memory hog that should go OOM quickly stalls for > >>> several minutes before stalling. In Mike and Darrick's cases, a small > >>> memcg environment stalled excessively even though the system had enough > >>> memory overall. > >> > >> Just wondering: this patch afaics is now in -mm and Linux next for > >> nearly two weeks. Is that intentional? I had expected it to be mainlined > >> with the batch of patches Andrew mailed to Linus last week, but it > >> wasn't among them. > > > > I have it queued for 5.17-rc1. > > > > There is still time to squeeze it into 5.16, just, with a cc:stable. > > > > Alternatively we could merge it into 5.17-rc1 with a cc:stable, so it > > will trickle back with less risk to the 5.17 release. > > > > What do people think? > > CCing Linus, to make sure he's aware of this. > > Maybe I'm totally missing something, but I'm a bit confused by what you > wrote, as the regression afaik was introduced between v5.15..v5.16-rc1. > So I assume this is what you meant: > > ``` > I have it queued for 5.17-rc1. > > There is still time to squeeze it into 5.16. > > Alternatively we could merge it into 5.17-rc1 with a cc:stable, so it > will trickle back with less risk to the 5.16 release. > > What do people think? > ``` > > I'll leave the individual risk evaluation of the patch to others. If the > fix is risky, waiting for 5.17 is fine for me. > > But hmmm, regarding the "could merge it into 5.17-rc1 with a cc:stable" > idea a remark: is that really "less risk", as your stated? > > If we get it into rc8 (which is still possible, even if a bit hard due > to the new year festivities), it will get at least one week of testing. My vote is for it to go into rc8: for me, 5.16-rc reclaim behaves too oddly without it, so I've simply added it into whatever testing I do ever since Mel posted - no regressions noticed with it in (aside from needing the -fix.patch you already added a few weeks ago). Hugh > > If the fix waits for the next merge window, it all depends on the how > the timing works out. But it's easy to picture a worst case: the fix is > only merged on the Friday evening before Linus releases 5.17-rc1 and > right after it's out makes it into a stable-rc (say a day or two after > 5.17-rc1 is out) and from there into a 5.16.y release on Thursday. That > IMHO would mean less days of testing in the end (and there is a weekend > in this period as well). > > Waiting obviously will also mean that users of 5.16 and 5.16.y will > likely have to face this regression for at least two and a half weeks, > unless you send the fix early and Greg backports it before rc1 (which he > afaics does if there are good reasons). Yes, it's `just` a performance > regression, so it might not stop anyone from running Linux 5.16 -- but > it's one that three people separately reported in the 5.16 devel cycle, > so others will likely encounter it as well if we leave it unfixed in > 5.16. This will likely annoy some people, especially if they invest time > in bisecting it, only to find out that the forth iteration of the fix > for the regression is already available since December the 2nd. > > Ciao, Thorsten
next prev parent reply other threads:[~2021-12-31 18:34 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 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 [this message] 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 \ --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 \ --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).