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

[Ridong Chen <ridong.chen@linux.dev>]

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