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

[Roman Gushchin <roman.gushchin@linux.dev>]

"Lorenzo Stoakes (ARM)" <ljs@kernel.org> writes:

> +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.

I thought about it, but switching it off completely looks dubious to
me. So maybe moderating it a bit can help? Like not reporting completely
unrelated issues or at least do not report them more than once?
Even if it's only 50% accurate, 50% chance of missing a critical/high severity
bug (other are not reported) sounds bad.

But also I feel like there should be no expectations on fixing
pre-existing issues as something _required_ to land a patch.
It's always a best effort thing.

> Maybe we could figure out a way of funnelling this stuff somewhere separately
> longer term.

Yes, there will be a database available to maintainers soon.

>
> (I have I think 2 slopped fixes to rewrite after the previous what like 7 or 8
> this cycle? So forgive the grumpiness :)

No problems :)