Re: [PATCH v3 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim
From: Ridong Chen
Date: Thu Aug 13 2026 - 22:38:08 EST
On 8/14/2026 10:23 AM, Barry Song wrote:
On Fri, Aug 14, 2026 at 10:03 AM Ridong Chen <ridong.chen@xxxxxxxxx> wrote:Yeah, good point. I'll give it a try and run some tests to see if it actually helps.
[...]
On 8/14/2026 6:37 AM, Barry Song wrote:
On Tue, Jul 28, 2026 at 4:34 PM Ridong Chen <ridong.chen@xxxxxxxxx> wrote:
On 7/24/2026 7:12 PM, Barry Song wrote:
On Fri, Jul 24, 2026 at 10:43 AM Ridong Chen <ridong.chen@xxxxxxxxx> wrote:
On 7/24/2026 8:18 AM, Andrew Morton wrote:
For example, Maybe we can skip shrink_slab when node_page_state_pages(pgdat,
So can we add just like?
if ((sc->proactive && node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) >
pgdat->min_slab_pages) ||
node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages ||
node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > pgdat->min_slab_pages) {
I feel both pgdat->min_unmapped_pages and
pgdat->min_slab_pages are quite broken in mainline.
For example, even when the page cache is below
min_unmapped_pages, it may still be reclaimed. Similarly, slab may
still be reclaimed even when it is below min_slab_pages.
Also, when both the page cache and slab are below their respective
thresholds, node_reclaim() may reclaim nothing even if we have
plenty of anon folios available.
if (node_pagecache_reclaimable(pgdat) <= pgdat->min_unmapped_pages &&
node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) <=
pgdat->min_slab_pages)
return 0;
For example, if slab > min_slab_pages but the page cache is below
min_unmapped_pages, we still reclaim file pages, even though the
comment says we should not.
So we are not going to introduce another broken mechanism.
Maybe we should start by fixing the existing broken protection
against reclaiming slab and page cache?
NR_SLAB_RECLAIMABLE_B) <= pgdat->min_slab_pages?
And similarly, in get_scan_count, we could avoid reclaiming file page cache if
node_pagecache_reclaimable(pgdat) <= pgdat->min_unmapped_pages.
Yes, probably something along the lines of what you're saying. Also,
get_type_to_scan() in MGLRU.
It's a bit surprising that nobody has ever reported a bug related to
this. It may have caused performance problems that we simply haven't
realized were related to this broken protection against the
min_unmapped_pages and min_slab_pages thresholds.
I guess this fix could improve performance as well. For example, when
the inode and dentry caches are already extremely low, we shouldn't
keep struggling to reclaim them and waste time there. People have
already complained that shrink_slab() is slow and suggested having
an asynchronous shrinker for it.
Maybe it's related to something going wrong here.
--
Best regards
Ridong