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

[Michal Hocko <mhocko@suse.com>]

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