From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Hui Zhu <hui.zhu@linux.dev>,
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>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Hui Zhu <zhuhui@kylinos.cn>
Subject: Re: [PATCH mm-unstable v2 2/2] mm/vmscan: apply too_many_isolated() throttling to MGLRU eviction
Date: Tue, 18 Aug 2026 11:36:14 +0800 [thread overview]
Message-ID: <e5c15b42-55e9-4912-9000-cd720a44b57b@linux.alibaba.com> (raw)
In-Reply-To: <858e2e0ae536bbe185267472d3c84a5684937131.1786950138.git.zhuhui@kylinos.cn>
On 8/17/26 3:11 PM, Hui Zhu wrote:
> From: Hui Zhu <zhuhui@kylinos.cn>
>
> The legacy path throttles direct reclaim in shrink_inactive_list()
> when too many isolated folios pile up, but MGLRU's evict_folios()
> isolates folios without this check, which can lead to unnecessary
> swapping, thrashing and OOM.
>
> With the NR_ISOLATED counters now updated in evict_folios(), extract
> the throttling loop from shrink_inactive_list() into
> throttle_isolated() and reuse it in evict_folios(). The type to
> isolate is predicted with get_type_to_scan() since it is unknown
> until isolation.
>
> If a fatal signal is pending, fake reclaim progress the same way the
> legacy path does, so the dying task exits reclaim quickly instead of
> being held in the throttle.
>
> Signed-off-by: Hui Zhu <zhuhui@kylinos.cn>
> ---
> mm/vmscan.c | 67 ++++++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 56 insertions(+), 11 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fdc45d7d8fba..886a53f563ab 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1819,7 +1819,7 @@ bool folio_isolate_lru(struct folio *folio)
> * the LRU list will go small and be scanned faster than necessary, leading to
> * unnecessary swapping, thrashing and OOM.
> */
> -static bool too_many_isolated(struct pglist_data *pgdat, int file,
> +static bool too_many_isolated(struct pglist_data *pgdat, bool file,
> struct scan_control *sc)
> {
> unsigned long inactive, isolated;
> @@ -1856,6 +1856,37 @@ static bool too_many_isolated(struct pglist_data *pgdat, int file,
> return too_many;
> }
>
> +/*
> + * Throttle reclaim if too many isolated folios are piling up. If this makes
> + * no progress, the caller is probably looping on unevictable folios, so give
> + * up. Returns false to tell the caller to stop reclaiming, and sets @fatal
> + * if the task received a fatal signal while waiting, so that the caller can
> + * bail out faster.
> + */
> +static bool throttle_isolated(struct pglist_data *pgdat, bool file,
> + struct scan_control *sc, bool *fatal)
> +{
> + bool stalled = false;
> +
> + *fatal = false;
> + while (unlikely(too_many_isolated(pgdat, file, sc))) {
> + if (stalled)
> + return false;
> +
> + /* wait a bit for the reclaimer. */
> + stalled = true;
> + reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED);
> +
> + /* We are about to die and free our memory. Return now. */
> + if (fatal_signal_pending(current)) {
> + *fatal = true;
> + return false;
> + }
> + }
> +
> + return true;
Returning ‘true’ or 'false' looks confusing to me, maybe use a readable
variable 'is_throttled'?
> +}
> +
> /*
> * move_folios_to_lru() moves folios from private @list to appropriate LRU list.
> *
> @@ -1992,19 +2023,14 @@ static unsigned long shrink_inactive_list(unsigned long nr_to_scan,
> bool file = is_file_lru(lru);
> enum node_stat_item item;
> struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> - bool stalled = false;
> -
> - while (unlikely(too_many_isolated(pgdat, file, sc))) {
> - if (stalled)
> - return 0;
> -
> - /* wait a bit for the reclaimer. */
> - stalled = true;
> - reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED);
> + bool fatal;
>
> + if (!throttle_isolated(pgdat, file, sc, &fatal)) {
> /* We are about to die and free our memory. Return now. */
> - if (fatal_signal_pending(current))
> + if (fatal)
> return SWAP_CLUSTER_MAX;
> +
> + return 0;
> }
>
> lru_add_drain();
> @@ -4883,6 +4909,25 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
> bool skip_retry = false;
> struct mem_cgroup *memcg = lruvec_memcg(lruvec);
> struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> + bool fatal;
> +
> + /*
> + * The type to isolate is unknown until isolation, so predict it for
> + * the throttling check. isolate_folios() may still fall back to the
> + * other type, which is fine for this heuristic.
> + */
> + type = get_type_to_scan(lruvec, swappiness);
Perhaps we could use 'for_each_evictable_type(i, swappiness)' to check
each type's isolation?
> + if (!throttle_isolated(pgdat, type, sc, &fatal)) {
> + /*
> + * We are about to die and free our memory. Like the legacy
> + * path, pretend some pages were reclaimed so reclaim unwinds
> + * quickly instead of looping back into the throttle.
> + */
> + if (fatal)
> + sc->nr_reclaimed += SWAP_CLUSTER_MAX;
> +
> + return 0;
> + }
>
> lruvec_lock_irq(lruvec);
>
prev parent reply other threads:[~2026-08-18 3:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 7:11 [PATCH mm-unstable v2 0/2] mm/vmscan: fix NR_ISOLATED accounting and throttling for MGLRU Hui Zhu
2026-08-17 7:11 ` [PATCH mm-unstable v2 1/2] mm/vmscan: fix missing NR_ISOLATED counter update in MGLRU reclaim path Hui Zhu
2026-08-18 3:19 ` Baolin Wang
2026-08-17 7:11 ` [PATCH mm-unstable v2 2/2] mm/vmscan: apply too_many_isolated() throttling to MGLRU eviction Hui Zhu
2026-08-18 3:36 ` Baolin Wang [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=e5c15b42-55e9-4912-9000-cd720a44b57b@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hui.zhu@linux.dev \
--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 \
--cc=zhuhui@kylinos.cn \
/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