Re: [RFC PATCH 0/4] mm/vmscan: honour node reclaim limits per type
"Lorenzo Stoakes (ARM)" <[email protected]>
| Newsgroups | org.kvack.linux-mm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <aogQ6iDA7RkuTtDG@gremlin> |
+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 :)
--
Cheers, Lorenzo