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 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.