From: Ridong Chen <ridong.chen@linux.dev>
To: Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Lorenzo Stoakes <ljs@kernel.org>,
Kairui Song <kasong@tencent.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Zhongkun He <hezhongkun.hzk@bytedance.com>,
Muchun Song <muchun.song@linux.dev>,
Davidlohr Bueso <dave@stgolabs.net>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Ridong Chen <chenridong@xiaomi.com>
Subject: Re: [PATCH v3 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim
Date: Fri, 14 Aug 2026 10:37:51 +0800 [thread overview]
Message-ID: <76dd9011-84e3-45ac-a9a9-a772e5a15b1c@linux.dev> (raw)
In-Reply-To: <CAGsJ_4zSEutDjM0rwfDZrzDUzJvPSFsU8Pcr2kBJiOmG81CY7w@mail.gmail.com>
On 8/14/2026 10:23 AM, Barry Song wrote:
> On Fri, Aug 14, 2026 at 10:03 AM Ridong Chen <ridong.chen@linux.dev> wrote:
>>
>>
>>
>> On 8/14/2026 6:37 AM, Barry Song wrote:
>>> On Tue, Jul 28, 2026 at 4:34 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>>
>>>>
>>>>
>>>> On 7/24/2026 7:12 PM, Barry Song wrote:
>>>>> On Fri, Jul 24, 2026 at 10:43 AM Ridong Chen <ridong.chen@linux.dev> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/24/2026 8:18 AM, Andrew Morton wrote:
> [...]
>>>>
>>>> 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?
>>>
>> For example, Maybe we can skip shrink_slab when node_page_state_pages(pgdat,
>> 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.
>
Yeah, good point. I'll give it a try and run some tests to see if it actually helps.
--
Best regards
Ridong
prev parent reply other threads:[~2026-08-14 2:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 4:57 [PATCH v3 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim Ridong
2026-07-23 4:57 ` [PATCH v3 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max Ridong
2026-07-23 4:57 ` [PATCH v3 2/4] mm: vmscan: propagate real error code from per-node proactive reclaim Ridong
2026-07-23 4:57 ` [PATCH v3 3/4] mm: vmscan: drop unused gfp_mask parameter from __node_reclaim() Ridong
2026-07-23 4:57 ` [PATCH v3 4/4] mm/mglru: fix anon-only reclaim evicting file pages when swappiness=max Ridong
2026-07-23 8:57 ` Barry Song
2026-07-24 2:20 ` Ridong Chen
2026-07-24 0:18 ` [PATCH v3 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim Andrew Morton
2026-07-24 2:27 ` Ridong Chen
2026-07-24 2:43 ` Ridong Chen
2026-07-24 11:12 ` Barry Song
2026-07-28 8:33 ` Ridong Chen
2026-08-13 22:37 ` Barry Song
2026-08-14 2:03 ` Ridong Chen
2026-08-14 2:23 ` Barry Song
2026-08-14 2:37 ` Ridong Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76dd9011-84e3-45ac-a9a9-a772e5a15b1c@linux.dev \
--to=ridong.chen@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=chenridong@xiaomi.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hezhongkun.hzk@bytedance.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.