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

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
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.
-- 
Michal Hocko
SUSE Labs