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

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

[Ridong Chen]

From: Ridong Chen <chenridong@xiaomi.com>

min_unmapped_pages and min_slab_pages are documented as per-type limits,
but node reclaim treats them as one combined gate: once either is
exceeded, shrink_node() reclaims slab, file and anon together and pushes
the other type below its limit. Per-node proactive reclaim reuses the
same gate and fares worse -- with page cache and slab both under their
limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].

This series gates each type separately via two scan_control flags
(skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
drops the combined gate, and extends node_reclaim()'s early bail to check
anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
are unaffected.

Tested on QEMU (x86_64, 2 NUMA nodes), A/B kernels differing only in this
series.

Proactive reclaim (echo to node/reclaim) on an anon-heavy node, file and
slab under their limits:

  metric              before   after
  -----------------   ------   -----------
  pages reclaimed     0 MiB    254 MiB anon
  return value        -EAGAIN  0

Node reclaim (zone_reclaim_mode) with one type under its limit -- the type
under its limit must be left alone:

  type under limit    before          after
  -----------------   -------------   --------
  slab                645 scans       0 scans
  page cache          83 MiB scanned  0 MiB

[1] https://sashiko.dev/#/patchset/20260723045718.2052070-1-ridong.chen@linux.dev

Ridong Chen (4):
  mm/vmscan: only reclaim slab in node reclaim when over min_slab_pages
  mm/vmscan: only reclaim file pages in node reclaim when over
    min_unmapped_pages
  mm/vmscan: drop the combined limit gate in __node_reclaim()
  mm/vmscan: do not skip node reclaim when only anon is reclaimable

 mm/vmscan.c | 89 ++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 67 insertions(+), 22 deletions(-)

-- 
2.34.1

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

[Ridong Chen]

From: Ridong Chen <chenridong@xiaomi.com>

min_unmapped_pages and min_slab_pages are documented as per-type limits,
but node reclaim treats them as one combined gate: once either is
exceeded, shrink_node() reclaims slab, file and anon together and pushes
the other type below its limit. Per-node proactive reclaim reuses the
same gate and fares worse -- with page cache and slab both under their
limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].

This series gates each type separately via two scan_control flags
(skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
drops the combined gate, and extends node_reclaim()'s early bail to check
anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
are unaffected.

Tested on QEMU (x86_64, 2 NUMA nodes), A/B kernels differing only in this
series.

Proactive reclaim (echo to node/reclaim) on an anon-heavy node, file and
slab under their limits:

  metric              before   after
  -----------------   ------   -----------
  pages reclaimed     0 MiB    254 MiB anon
  return value        -EAGAIN  0

Node reclaim (zone_reclaim_mode) with one type under its limit -- the type
under its limit must be left alone:

  type under limit    before          after
  -----------------   -------------   --------
  slab                645 scans       0 scans
  page cache          83 MiB scanned  0 MiB

[1] https://sashiko.dev/#/patchset/20260723045718.2052070-1-ridong.chen@linux.dev

Ridong Chen (4):
  mm/vmscan: only reclaim slab in node reclaim when over min_slab_pages
  mm/vmscan: only reclaim file pages in node reclaim when over
    min_unmapped_pages
  mm/vmscan: drop the combined limit gate in __node_reclaim()
  mm/vmscan: do not skip node reclaim when only anon is reclaimable

 mm/vmscan.c | 89 ++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 67 insertions(+), 22 deletions(-)

-- 
2.34.1

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

[Michal Hocko]

On Fri 21-08-26 16:17:37, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xiaomi.com>
> 
> min_unmapped_pages and min_slab_pages are documented as per-type limits,
> but node reclaim treats them as one combined gate: once either is
> exceeded, shrink_node() reclaims slab, file and anon together and pushes
> the other type below its limit. Per-node proactive reclaim reuses the
> same gate and fares worse -- with page cache and slab both under their
> limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].
> 
> This series gates each type separately via two scan_control flags
> (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
> drops the combined gate, and extends node_reclaim()'s early bail to check
> anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
> are unaffected.

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?

> Tested on QEMU (x86_64, 2 NUMA nodes), A/B kernels differing only in this
> series.
> 
> Proactive reclaim (echo to node/reclaim) on an anon-heavy node, file and
> slab under their limits:
> 
>   metric              before   after
>   -----------------   ------   -----------
>   pages reclaimed     0 MiB    254 MiB anon
>   return value        -EAGAIN  0
> 
> Node reclaim (zone_reclaim_mode) with one type under its limit -- the type
> under its limit must be left alone:
> 
>   type under limit    before          after
>   -----------------   -------------   --------
>   slab                645 scans       0 scans
>   page cache          83 MiB scanned  0 MiB
> 
> [1] https://sashiko.dev/#/patchset/20260723045718.2052070-1-ridong.chen@linux.dev
> 
> Ridong Chen (4):
>   mm/vmscan: only reclaim slab in node reclaim when over min_slab_pages
>   mm/vmscan: only reclaim file pages in node reclaim when over
>     min_unmapped_pages
>   mm/vmscan: drop the combined limit gate in __node_reclaim()
>   mm/vmscan: do not skip node reclaim when only anon is reclaimable
> 
>  mm/vmscan.c | 89 ++++++++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 67 insertions(+), 22 deletions(-)
> 
> -- 
> 2.34.1

-- 
Michal Hocko
SUSE Labs

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

[Lorenzo Stoakes (ARM)]

+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

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

[Ridong Chen]

On 8/21/2026 4:31 PM, Michal Hocko wrote:
> On Fri 21-08-26 16:17:37, Ridong Chen wrote:
>> From: Ridong Chen <chenridong@xiaomi.com>
>>
>> min_unmapped_pages and min_slab_pages are documented as per-type limits,
>> but node reclaim treats them as one combined gate: once either is
>> exceeded, shrink_node() reclaims slab, file and anon together and pushes
>> the other type below its limit. Per-node proactive reclaim reuses the
>> same gate and fares worse -- with page cache and slab both under their
>> limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].
>>
>> This series gates each type separately via two scan_control flags
>> (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
>> drops the combined gate, and extends node_reclaim()'s early bail to check
>> anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
>> are unaffected.
> 
> 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?
> 

Hi Michal,

Thank you for your reply. I should have made the background much clearer.

Yes, the original issue comes from Sashiko's review. Sashiko found that 
proactive reclaim fails to reclaim memory when the node's unmapped file or slab 
pages are below the minimum thresholds, even though there is plenty of anonymous 
memory available.

After further discussion, we realized that min_unmapped_pages and min_slab_pages 
may not be used correctly. Apart from the issue above, there are other problems 
as mentioned by Barry in [2]:

Even when page cache is below min_unmapped_pages, it may still be reclaimed as 
long as slab is sufficient. Similarly, slab may still be reclaimed even when it 
is below min_slab_pages.

node_reclaim() cannot reclaim anonymous pages if both page cache and slab are 
below their respective thresholds, even when there is plenty of anonymous memory 
available.

To address these issues, I am sending this series to facilitate discussion. Your 
feedback would be greatly appreciated.

[2] 
https://lore.kernel.org/linux-mm/CAGsJ_4xCi1TzV0sg=8ZFhfAq7v=k=Q6a10DNDouYOrjcJL-5=A@mail.gmail.com/

>> Tested on QEMU (x86_64, 2 NUMA nodes), A/B kernels differing only in this
>> series.
>>
>> Proactive reclaim (echo to node/reclaim) on an anon-heavy node, file and
>> slab under their limits:
>>
>>    metric              before   after
>>    -----------------   ------   -----------
>>    pages reclaimed     0 MiB    254 MiB anon
>>    return value        -EAGAIN  0
>>
>> Node reclaim (zone_reclaim_mode) with one type under its limit -- the type
>> under its limit must be left alone:
>>
>>    type under limit    before          after
>>    -----------------   -------------   --------
>>    slab                645 scans       0 scans
>>    page cache          83 MiB scanned  0 MiB
>>
>> [1] https://sashiko.dev/#/patchset/20260723045718.2052070-1-ridong.chen@linux.dev
>>
>> Ridong Chen (4):
>>    mm/vmscan: only reclaim slab in node reclaim when over min_slab_pages
>>    mm/vmscan: only reclaim file pages in node reclaim when over
>>      min_unmapped_pages
>>    mm/vmscan: drop the combined limit gate in __node_reclaim()
>>    mm/vmscan: do not skip node reclaim when only anon is reclaimable
>>
>>   mm/vmscan.c | 89 ++++++++++++++++++++++++++++++++++++++++-------------
>>   1 file changed, 67 insertions(+), 22 deletions(-)
>>
>> -- 
>> 2.34.1
> 

-- 
Best regards
Ridong

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

[Michal Hocko]

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

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

[Michal Hocko]

On Fri 21-08-26 17:07:32, Ridong Chen wrote:
> 
> 
> On 8/21/2026 4:31 PM, Michal Hocko wrote:
> > On Fri 21-08-26 16:17:37, Ridong Chen wrote:
> > > From: Ridong Chen <chenridong@xiaomi.com>
> > > 
> > > min_unmapped_pages and min_slab_pages are documented as per-type limits,
> > > but node reclaim treats them as one combined gate: once either is
> > > exceeded, shrink_node() reclaims slab, file and anon together and pushes
> > > the other type below its limit. Per-node proactive reclaim reuses the
> > > same gate and fares worse -- with page cache and slab both under their
> > > limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].
> > > 
> > > This series gates each type separately via two scan_control flags
> > > (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
> > > drops the combined gate, and extends node_reclaim()'s early bail to check
> > > anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
> > > are unaffected.
> > 
> > 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?
> > 
> 
> Hi Michal,
> 
> Thank you for your reply. I should have made the background much clearer.
> 
> Yes, the original issue comes from Sashiko's review. Sashiko found that
> proactive reclaim fails to reclaim memory when the node's unmapped file or
> slab pages are below the minimum thresholds, even though there is plenty of
> anonymous memory available.
> 
> After further discussion, we realized that min_unmapped_pages and
> min_slab_pages may not be used correctly. Apart from the issue above, there
> are other problems as mentioned by Barry in [2]:
> 
> Even when page cache is below min_unmapped_pages, it may still be reclaimed
> as long as slab is sufficient. Similarly, slab may still be reclaimed even
> when it is below min_slab_pages.
> 
> node_reclaim() cannot reclaim anonymous pages if both page cache and slab
> are below their respective thresholds, even when there is plenty of
> anonymous memory available.
> 
> To address these issues, I am sending this series to facilitate discussion.
> Your feedback would be greatly appreciated.

Those interfaces are relicts from the distant past same as the node
reclaim. I wouldn't bother fixing those unless there is a real usecase.
Pro-active per node reclaim is a different thing and we should probably
divorce it from those min_$foo counters altogether (if they are not
yet).

Same as checkpatch.pl, shashiko is giving you hints and you shouldn't
simply follow them without a deeper considerations. Consider that there
is review capacity required for any patch posted. We do not want to
waste that scarce resource.

-- 
Michal Hocko
SUSE Labs

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

[Ridong Chen]

On 8/21/2026 5:24 PM, Michal Hocko wrote:
> On Fri 21-08-26 17:07:32, Ridong Chen wrote:
>>
>>
>> On 8/21/2026 4:31 PM, Michal Hocko wrote:
>>> On Fri 21-08-26 16:17:37, Ridong Chen wrote:
>>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>>
>>>> min_unmapped_pages and min_slab_pages are documented as per-type limits,
>>>> but node reclaim treats them as one combined gate: once either is
>>>> exceeded, shrink_node() reclaims slab, file and anon together and pushes
>>>> the other type below its limit. Per-node proactive reclaim reuses the
>>>> same gate and fares worse -- with page cache and slab both under their
>>>> limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].
>>>>
>>>> This series gates each type separately via two scan_control flags
>>>> (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
>>>> drops the combined gate, and extends node_reclaim()'s early bail to check
>>>> anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
>>>> are unaffected.
>>>
>>> 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?
>>>
>>
>> Hi Michal,
>>
>> Thank you for your reply. I should have made the background much clearer.
>>
>> Yes, the original issue comes from Sashiko's review. Sashiko found that
>> proactive reclaim fails to reclaim memory when the node's unmapped file or
>> slab pages are below the minimum thresholds, even though there is plenty of
>> anonymous memory available.
>>
>> After further discussion, we realized that min_unmapped_pages and
>> min_slab_pages may not be used correctly. Apart from the issue above, there
>> are other problems as mentioned by Barry in [2]:
>>
>> Even when page cache is below min_unmapped_pages, it may still be reclaimed
>> as long as slab is sufficient. Similarly, slab may still be reclaimed even
>> when it is below min_slab_pages.
>>
>> node_reclaim() cannot reclaim anonymous pages if both page cache and slab
>> are below their respective thresholds, even when there is plenty of
>> anonymous memory available.
>>
>> To address these issues, I am sending this series to facilitate discussion.
>> Your feedback would be greatly appreciated.
> 
> Those interfaces are relicts from the distant past same as the node
> reclaim. I wouldn't bother fixing those unless there is a real usecase.
> Pro-active per node reclaim is a different thing and we should probably
> divorce it from those min_$foo counters altogether (if they are not
> yet).
> 

Yeah, proactive per-node reclaim currently does not divorce from those min_$foo 
counters.

Did you mean that min_slab_pages and min_unmapped_pages should influence 
proactive per-node reclaim? If so, perhaps the easiest fix would be something 
like this:

```
static unsigned long __node_reclaim(struct pglist_data *pgdat,
				    unsigned long nr_pages,
				    struct scan_control *sc)
{
...
if (sc->proactive ||
     node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages ||
     node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > pgdat->min_slab_pages) {
	do {
			shrink_node(pgdat, sc);
	} while (sc->nr_reclaimed < nr_pages && --sc->priority >= 0);
}
...
}
```

> Same as checkpatch.pl, shashiko is giving you hints and you shouldn't
> simply follow them without a deeper considerations. Consider that there
> is review capacity required for any patch posted. We do not want to
> waste that scarce resource.
> 

You are right. I should be more considerate. Sometimes, due to my lack of 
experience, I cannot come up with a good solution on my own, so I send RFCs to 
gather professional opinions. Thank you for your time and guidance.

-- 
Best regards
Ridong

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

[Michal Hocko]

On Fri 21-08-26 18:52:12, Ridong Chen wrote:
> 
> 
> On 8/21/2026 5:24 PM, Michal Hocko wrote:
> > On Fri 21-08-26 17:07:32, Ridong Chen wrote:
> > > 
> > > 
> > > On 8/21/2026 4:31 PM, Michal Hocko wrote:
> > > > On Fri 21-08-26 16:17:37, Ridong Chen wrote:
> > > > > From: Ridong Chen <chenridong@xiaomi.com>
> > > > > 
> > > > > min_unmapped_pages and min_slab_pages are documented as per-type limits,
> > > > > but node reclaim treats them as one combined gate: once either is
> > > > > exceeded, shrink_node() reclaims slab, file and anon together and pushes
> > > > > the other type below its limit. Per-node proactive reclaim reuses the
> > > > > same gate and fares worse -- with page cache and slab both under their
> > > > > limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].
> > > > > 
> > > > > This series gates each type separately via two scan_control flags
> > > > > (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
> > > > > drops the combined gate, and extends node_reclaim()'s early bail to check
> > > > > anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
> > > > > are unaffected.
> > > > 
> > > > 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?
> > > > 
> > > 
> > > Hi Michal,
> > > 
> > > Thank you for your reply. I should have made the background much clearer.
> > > 
> > > Yes, the original issue comes from Sashiko's review. Sashiko found that
> > > proactive reclaim fails to reclaim memory when the node's unmapped file or
> > > slab pages are below the minimum thresholds, even though there is plenty of
> > > anonymous memory available.
> > > 
> > > After further discussion, we realized that min_unmapped_pages and
> > > min_slab_pages may not be used correctly. Apart from the issue above, there
> > > are other problems as mentioned by Barry in [2]:
> > > 
> > > Even when page cache is below min_unmapped_pages, it may still be reclaimed
> > > as long as slab is sufficient. Similarly, slab may still be reclaimed even
> > > when it is below min_slab_pages.
> > > 
> > > node_reclaim() cannot reclaim anonymous pages if both page cache and slab
> > > are below their respective thresholds, even when there is plenty of
> > > anonymous memory available.
> > > 
> > > To address these issues, I am sending this series to facilitate discussion.
> > > Your feedback would be greatly appreciated.
> > 
> > Those interfaces are relicts from the distant past same as the node
> > reclaim. I wouldn't bother fixing those unless there is a real usecase.
> > Pro-active per node reclaim is a different thing and we should probably
> > divorce it from those min_$foo counters altogether (if they are not
> > yet).
> > 
> 
> Yeah, proactive per-node reclaim currently does not divorce from those
> min_$foo counters.
> 
> Did you mean that min_slab_pages and min_unmapped_pages should influence
> proactive per-node reclaim?

Nope, exactly opposite

-- 
Michal Hocko
SUSE Labs

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

[Ridong Chen]

On 8/21/2026 7:02 PM, Michal Hocko wrote:
> On Fri 21-08-26 18:52:12, Ridong Chen wrote:
>>
>>
>> On 8/21/2026 5:24 PM, Michal Hocko wrote:
>>> On Fri 21-08-26 17:07:32, Ridong Chen wrote:
>>>>
>>>>
>>>> On 8/21/2026 4:31 PM, Michal Hocko wrote:
>>>>> On Fri 21-08-26 16:17:37, Ridong Chen wrote:
>>>>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>>>>
>>>>>> min_unmapped_pages and min_slab_pages are documented as per-type limits,
>>>>>> but node reclaim treats them as one combined gate: once either is
>>>>>> exceeded, shrink_node() reclaims slab, file and anon together and pushes
>>>>>> the other type below its limit. Per-node proactive reclaim reuses the
>>>>>> same gate and fares worse -- with page cache and slab both under their
>>>>>> limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1].
>>>>>>
>>>>>> This series gates each type separately via two scan_control flags
>>>>>> (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path,
>>>>>> drops the combined gate, and extends node_reclaim()'s early bail to check
>>>>>> anon. The flags default to zero, so kswapd, direct, memcg and drop_caches
>>>>>> are unaffected.
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> Hi Michal,
>>>>
>>>> Thank you for your reply. I should have made the background much clearer.
>>>>
>>>> Yes, the original issue comes from Sashiko's review. Sashiko found that
>>>> proactive reclaim fails to reclaim memory when the node's unmapped file or
>>>> slab pages are below the minimum thresholds, even though there is plenty of
>>>> anonymous memory available.
>>>>
>>>> After further discussion, we realized that min_unmapped_pages and
>>>> min_slab_pages may not be used correctly. Apart from the issue above, there
>>>> are other problems as mentioned by Barry in [2]:
>>>>
>>>> Even when page cache is below min_unmapped_pages, it may still be reclaimed
>>>> as long as slab is sufficient. Similarly, slab may still be reclaimed even
>>>> when it is below min_slab_pages.
>>>>
>>>> node_reclaim() cannot reclaim anonymous pages if both page cache and slab
>>>> are below their respective thresholds, even when there is plenty of
>>>> anonymous memory available.
>>>>
>>>> To address these issues, I am sending this series to facilitate discussion.
>>>> Your feedback would be greatly appreciated.
>>>
>>> Those interfaces are relicts from the distant past same as the node
>>> reclaim. I wouldn't bother fixing those unless there is a real usecase.
>>> Pro-active per node reclaim is a different thing and we should probably
>>> divorce it from those min_$foo counters altogether (if they are not
>>> yet).
>>>
>>
>> Yeah, proactive per-node reclaim currently does not divorce from those
>> min_$foo counters.
>>
>> Did you mean that min_slab_pages and min_unmapped_pages should influence
>> proactive per-node reclaim?
> 
> Nope, exactly opposite
> 

I would really appreciate it if you could clarify this further. Sorry, I'm not 
sure I fully understand what you meant.

-- 
Best regards
Ridong

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

[Lorenzo Stoakes (ARM)]

On Fri, Aug 21, 2026 at 11:21:31AM +0200, Michal Hocko wrote:
> 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

I mean it's not only this case, it's a pattern I've been observing for a
while.

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

Yes this is a needed change in mm, but until we fully transition workflow
any patch might still land.

And I still find those kinds of suggestions deeply problematic for reviewer
workload.

If you had a person repeatedly say 'hey unrelated to this series but...'
you'd very quickly ask them to stop and if they persisted, >/dev/null them.

I get that passive passes are too expensive and it's not that much more
work to have sashiko point this stuff out, but it's not that much more work
for _it_, it's substantially increasing workload for reviewers.

As I said on a recent call - it's fine as long as you don't care about
reviewer/maintainer burnout.

But I do so :)

> --
> Michal Hocko
> SUSE Labs

--
Cheers, Lorenzo

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

[Michal Hocko]

On Fri 21-08-26 19:10:45, Ridong Chen wrote:
> > > Did you mean that min_slab_pages and min_unmapped_pages should influence
> > > proactive per-node reclaim?
> > 
> > Nope, exactly opposite
> > 
> 
> I would really appreciate it if you could clarify this further. Sorry, I'm
> not sure I fully understand what you meant.

pro-active (userspace triggered) node reclaim should completely ignore
all those historical node_reclaim tunables.
-- 
Michal Hocko
SUSE Labs

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

[Michal Hocko]

On Fri 21-08-26 12:16:47, Lorenzo Stoakes (ARM) wrote:
> On Fri, Aug 21, 2026 at 11:21:31AM +0200, Michal Hocko wrote:
> > 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
> 
> I mean it's not only this case, it's a pattern I've been observing for a
> while.

Yes, I know.

> > 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.
> 
> Yes this is a needed change in mm, but until we fully transition workflow
> any patch might still land.
> 
> And I still find those kinds of suggestions deeply problematic for reviewer
> workload.
> 
> If you had a person repeatedly say 'hey unrelated to this series but...'
> you'd very quickly ask them to stop and if they persisted, >/dev/null them.
> 
> I get that passive passes are too expensive and it's not that much more
> work to have sashiko point this stuff out, but it's not that much more work
> for _it_, it's substantially increasing workload for reviewers.
> 
> As I said on a recent call - it's fine as long as you don't care about
> reviewer/maintainer burnout.
> 
> But I do so :)

Hey, do not get me wrong. I very much care about reviewers as well. I
merely wanted to say that we've had peaks of tool driven patches no
matter what. Things have eventually normalized but people need to be
educated about expectations of maintainers. Sashiko suggesting "but this
might need attention as well..." certainly contribute to more noise but
keep in mind that AI driven people are going to find a tool of their
choice to arm them with ideas to implement and post so focusing on
Sashiko is not going to help all that much. My main message is to
establish and enforce a notion that patches are going to be ignored if
they are not justified properly (even if they might seem technically
correct or fixing a theoretical problem).
-- 
Michal Hocko
SUSE Labs