linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>,
	Mel Gorman <mgorman@techsingularity.net>,
	Mark Brown <broonie@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Alexey Avramov <hakavlad@inbox.lv>,
	Rik van Riel <riel@surriel.com>, Mike Galbraith <efault@gmx.de>,
	Darrick Wong <djwong@kernel.org>,
	regressions@lists.linux.dev,
	Linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.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: <d11ab9e-c258-a766-baa5-f11e56b7285@google.com> (raw)
In-Reply-To: <5c9d7c6b-05cd-4d17-b941-a93d90197cd3@leemhuis.info>

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 <regressions@leemhuis.info> 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

  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 \
    --in-reply-to=d11ab9e-c258-a766-baa5-f11e56b7285@google.com \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=djwong@kernel.org \
    --cc=efault@gmx.de \
    --cc=hakavlad@inbox.lv \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --cc=riel@surriel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --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).