Re: [RFC PATCH 0/4] mm/vmscan: honour node reclaim limits per type

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Aug 21, 2026 at 11:21:31AM +0200, Michal Hocko wrote:
> On Fri 21-08-26 09:58:52, Lorenzo Stoakes (ARM) wrote:
> > +cc Roman for suggestion.
> >
> > On Fri, Aug 21, 2026 at 10:31:06AM +0200, Michal Hocko wrote:
> > > You are explaining what but missing the most important part _Why_ do we
> > > need to have this addressed? Is this just addressing Sashiko review
> > > refernced below? Is there any real usecase where the current behavior
> > > matters?
> >
> > This is exactly the issue with these 'unrelated to your patch but' suggestions
> > from sashiko.
> >
> > You end up in loops:
> >
> >         AI generated patch --------------->  AI generated review
> >                   ^                                  |
> >                   |                                  |
> >                   |                                  v
> >                  AI generated 'unrelated to your patch but'
> >
> > And _at every stage_ reviewers have to do _additional work_ (with ~50% signal/noise).
> >
> > This isn't sustainable.
> >
> > We already had _too much work_ prior to the slopgeddon. Now we have a multiple
> > of that.
> >
> > Roman - I really think we a way of switching off the 'unrelated to your patch
> > but' stuff per-subsystem would be useful.
> >
> > Maybe we could figure out a way of funnelling this stuff somewhere separately
> > longer term.
> >
> > (I have I think 2 slopped fixes to rewrite after the previous what like 7 or 8
> > this cycle? So forgive the grumpiness :)
>
> I wouldn't blame Sashiko on this really. Yes it points to a theoretical
> problem. That is fine. But we should encourage people to not blindly

I mean it's not only this case, it's a pattern I've been observing for a
while.

> follow that lead and immediately jump at fixing something that is not a
> real problem. Quite honestly I even haven't looked into patches until it
> is clear that the usecase is sound. We should enforce this more and
> leave patches lingering if they are not sufficiently justified.

Yes this is a needed change in mm, but until we fully transition workflow
any patch might still land.

And I still find those kinds of suggestions deeply problematic for reviewer
workload.

If you had a person repeatedly say 'hey unrelated to this series but...'
you'd very quickly ask them to stop and if they persisted, >/dev/null them.

I get that passive passes are too expensive and it's not that much more
work to have sashiko point this stuff out, but it's not that much more work
for _it_, it's substantially increasing workload for reviewers.

As I said on a recent call - it's fine as long as you don't care about
reviewer/maintainer burnout.

But I do so :)

> --
> Michal Hocko
> SUSE Labs

--
Cheers, Lorenzo