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

From: Gregory Price

Date: Sat Aug 22 2026 - 00:51:01 EST


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