From: Zhang Peng <zippermonkey@icloud.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Baoquan He <baoquan.he@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Zhang Peng <bruzzhang@tencent.com>
Subject: [PATCH 0/4] mm/vmscan: refactor shrink_folio_list()
Date: Sun, 20 Sep 2026 22:24:13 +0800 [thread overview]
Message-ID: <20260920-vmscan-refactor-v1-0-ec04d71cb761@tencent.com> (raw)
shrink_folio_list() has grown into a very long function whose body mixes
several independent concerns: folio activation, the pageout() dispatch
state machine, the unmap step, and the final freeing path. The control
flow between them is expressed entirely through a chain of goto labels
(activate_locked, activate_locked_split, keep_locked, keep), which makes
it hard to see which decision each block actually reaches.
This series extracts four self-contained blocks into helpers, without
changing behaviour:
Patch 1: the activation block at activate_locked, into
folio_activate_locked().
Patch 2: the freeing path (buffer release, lazyfree, __remove_mapping,
folio_batch drain), into folio_try_reclaim_free().
Patch 3: the pageout() dispatch state machine, into
folio_try_pageout().
Patch 4: the TTU setup and try_to_unmap() block, into
folio_try_unmap().
Rather than returning a boolean, the extracted helpers return an explicit
result enum, so the reclaim decisions the caller has to make - activate,
keep, or reclaimed - stay visible at the call site instead of being
buried in the helper. Where a folio may be returned either locked or
unlocked, the result also records which, so the caller does not have to
infer the lock state from an invisible internal decision.
This is preparation for batching the dirty TLB flush before pageout,
which needs to call the pageout path from a second place. That change
will be posted separately once this cleanup has landed [1].
No functional change intended.
[1] https://lore.kernel.org/all/CAGsJ_4wrQRGjqavMzWgi2+PrRr1ztf4QRZEb6HKm02OF8nEBUQ@mail.gmail.com/
Suggested-by: Kairui Song <kasong@tencent.com>
Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
Zhang Peng (4):
mm/vmscan: introduce folio_activate_locked() helper
mm/vmscan: extract folio reclaim freeing from shrink_folio_list()
mm/vmscan: extract folio pageout from shrink_folio_list()
mm/vmscan: extract folio unmap logic into folio_try_unmap()
mm/vmscan.c | 376 +++++++++++++++++++++++++++++++++++-------------------------
1 file changed, 217 insertions(+), 159 deletions(-)
---
base-commit: 498ee28e5ec4727f829507c4a1bde3ab1b7704cd
change-id: 20260919-vmscan-refactor-1b3e5588af52
Best regards,
--
bruzzhang <bruzzhang@tencent.com>
next reply other threads:[~2026-09-20 14:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 14:24 Zhang Peng [this message]
2026-09-20 14:24 ` [PATCH 1/4] mm/vmscan: introduce folio_activate_locked() helper Zhang Peng
2026-09-20 14:24 ` [PATCH 2/4] mm/vmscan: extract folio reclaim freeing from shrink_folio_list() Zhang Peng
2026-09-20 14:24 ` [PATCH 3/4] mm/vmscan: extract folio pageout " Zhang Peng
2026-09-20 14:24 ` [PATCH 4/4] mm/vmscan: extract folio unmap logic into folio_try_unmap() Zhang Peng
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=20260920-vmscan-refactor-v1-0-ec04d71cb761@tencent.com \
--to=zippermonkey@icloud.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=bruzzhang@tencent.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=qi.zheng@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®