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

[Gregory Price <gourry@gourry.net>]

On Fri, Aug 21, 2026 at 09:58:52AM +0100, 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).
>

                We've been trying to reach you about
		your kernel's pre-existing conditions.

The reviewer piece aside - which I agree with (aggressively) - there's
actually some value on the first go-around of this cycle.  It has been
valuable to me in identifying bugs that are affecting my active
development areas - which is simultaneously frustrating and helpful.

Feels like ye olde map cycle problem - just break the chain at some
point and let it sit in a database and create a timeout on how often
sashiko can nag about a particular pre-existing bug.

If it keeps getting reported on - that means the area is under active
development and we should really address it.


Also - bugs is bugs.  Ignoring them is double plus bad.

~Gregory