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@xxxxxxxxxx>
> > > >
> > > > 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