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

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 <[email protected]>
>>>>>>
>>>>>> 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