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

[Michal Hocko]

On Fri 21-08-26 12:16:47, Lorenzo Stoakes (ARM) wrote:
> 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.

Yes, I know.

> > 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 :)

Hey, do not get me wrong. I very much care about reviewers as well. I
merely wanted to say that we've had peaks of tool driven patches no
matter what. Things have eventually normalized but people need to be
educated about expectations of maintainers. Sashiko suggesting "but this
might need attention as well..." certainly contribute to more noise but
keep in mind that AI driven people are going to find a tool of their
choice to arm them with ideas to implement and post so focusing on
Sashiko is not going to help all that much. My main message is to
establish and enforce a notion that patches are going to be ignored if
they are not justified properly (even if they might seem technically
correct or fixing a theoretical problem).
-- 
Michal Hocko
SUSE Labs