From: Barry Song <21cnbao@gmail.com>
To: Bingfang Guo <bfguo@icloud.com>
Cc: Yafang Shao <laoar.shao@gmail.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Kairui Song <ryncsn@gmail.com>,
BINGFANG GUO <bingfangguo@tencent.com>,
lenohou@gmail.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
weixugc@google.com, wjl.linux@gmail.com, yuzhao@google.com
Subject: Re: [PATCH] mm/mglru: fix cgroup OOM during MGLRU state switching
Date: Thu, 5 Mar 2026 12:45:43 +0800 [thread overview]
Message-ID: <CAGsJ_4zsM--Wzn6-EgRo23uCaii0bszFfRcuYrrKf=-cHgKmGA@mail.gmail.com> (raw)
In-Reply-To: <71281163-F081-456F-AFB0-37DC0470850A@icloud.com>
[...]
>
> --
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 614ccf39fe3f..d7ff7a6ed088 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2652,6 +2652,43 @@ static bool can_age_anon_pages(struct lruvec *lruvec,
>
> #ifdef CONFIG_LRU_GEN
>
> +DEFINE_STATIC_KEY_FALSE(lru_gen_draining);
> +
> +static inline bool lru_gen_is_draining(void)
> +{
> + return static_branch_unlikely(&lru_gen_draining);
> +}
> +
> +/*
> + * Lazily wait for the draining thread to finish if it's running.
> + *
> + * Return: whether we'd like to reclaim from multi-gen LRU.
> + */
> +static inline bool lru_gen_draining_wait(struct lruvec *lruvec, struct scan_control *sc)
> +{
> + bool global_enabled = lru_gen_enabled();
> +
> + /* Try reclaiming from the current LRU first */
> + if (sc->priority > DEF_PRIORITY / 2)
> + return READ_ONCE(lruvec->lrugen.enabled);
> +
> + /* Oops, try from the other side... */
> + if (sc->priority > 1)
> + return global_enabled;
> +
> + /*
> + * If we see lrugen.enabled is consistent here, when we get the lru
> + * spinlock, the migrating thread will have filled the lruvec with some
> + * pages, so we can continue without waiting.
> + */
> + while (global_enabled ^ READ_ONCE(lruvec->lrugen.enabled)) {
> + /* Not switching this one yet. Wait for a while. */
> + schedule_timeout_uninterruptible(1);
> + }
> +
> + return global_enabled;
> +}
Hi Bingfang,
Thanks very much for sharing. In my humble opinion, the code feels a
bit hacky. If we need to do something to reduce the probability of OOM
without fully fixing the issue, Leon’s approach—trying to reclaim from
both MGLRU and the active/inactive LRU during the transition—seems
less hacky, assuming they show the same likelihood of triggering OOM,
while still leaving some race conditions there.
> +
> #ifdef CONFIG_LRU_GEN_ENABLED
> DEFINE_STATIC_KEY_ARRAY_TRUE(lru_gen_caps, NR_LRU_GEN_CAPS);
> #define get_cap(cap) static_branch_likely(&lru_gen_caps[cap])
> @@ -5171,6 +5208,8 @@ static void lru_gen_change_state(bool enabled)
> if (enabled == lru_gen_enabled())
> goto unlock;
>
> + static_branch_enable_cpuslocked(&lru_gen_draining);
> +
> if (enabled)
> static_branch_enable_cpuslocked(&lru_gen_caps[LRU_GEN_CORE]);
> else
> @@ -5201,6 +5240,9 @@ static void lru_gen_change_state(bool enabled)
>
> cond_resched();
> } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)));
> +
> + static_branch_disable_cpuslocked(&lru_gen_draining);
> +
> unlock:
> mutex_unlock(&state_mutex);
> put_online_mems();
> @@ -5752,6 +5794,16 @@ late_initcall(init_lru_gen);
>
> #else /* !CONFIG_LRU_GEN */
>
> +static inline bool lru_gen_is_draining(void)
> +{
> + return false;
> +}
> +
> +static inline bool shrink_lruvec_draining(struct lruvec *lruvec, struct scan_control *sc)
> +{
> + return false;
> +}
> +
> static void lru_gen_age_node(struct pglist_data *pgdat, struct scan_control *sc)
> {
> BUILD_BUG();
> @@ -5780,7 +5832,10 @@ static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc)
> bool proportional_reclaim;
> struct blk_plug plug;
>
> - if (lru_gen_enabled() && !root_reclaim(sc)) {
> + if (lru_gen_is_draining() && lru_gen_draining_wait(lruvec, sc)) {
> + lru_gen_shrink_lruvec(lruvec, sc);
> + return;
> + } else if (lru_gen_enabled() && !root_reclaim(sc)) {
> lru_gen_shrink_lruvec(lruvec, sc);
> return;
> }
Thanks
Barry
next prev parent reply other threads:[~2026-03-05 4:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 16:10 Leno Hou
2026-02-28 18:58 ` Andrew Morton
2026-02-28 19:12 ` kernel test robot
2026-02-28 19:23 ` kernel test robot
2026-02-28 20:15 ` kernel test robot
2026-02-28 21:28 ` Barry Song
2026-02-28 22:41 ` Barry Song
2026-03-01 4:10 ` Barry Song
2026-03-02 5:50 ` Yafang Shao
2026-03-02 6:58 ` Barry Song
2026-03-02 7:43 ` Yafang Shao
2026-03-02 8:00 ` Kairui Song
2026-03-02 8:15 ` Barry Song
2026-03-02 8:25 ` Yafang Shao
2026-03-02 9:20 ` Barry Song
2026-03-02 9:47 ` Kairui Song
2026-03-02 14:35 ` Yafang Shao
2026-03-02 17:51 ` Yuanchu Xie
2026-03-03 1:34 ` Barry Song
2026-03-03 1:40 ` Axel Rasmussen
2026-03-03 2:43 ` Yafang Shao
2026-03-03 8:27 ` Bingfang Guo
2026-03-05 4:45 ` Barry Song [this message]
2026-03-02 16:26 ` Michal Hocko
2026-03-02 8:03 ` Barry Song
2026-03-02 8:13 ` Yafang Shao
2026-03-02 8:20 ` Barry Song
2026-03-03 6:37 Bingfang Guo
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='CAGsJ_4zsM--Wzn6-EgRo23uCaii0bszFfRcuYrrKf=-cHgKmGA@mail.gmail.com' \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=bfguo@icloud.com \
--cc=bingfangguo@tencent.com \
--cc=laoar.shao@gmail.com \
--cc=lenohou@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryncsn@gmail.com \
--cc=weixugc@google.com \
--cc=wjl.linux@gmail.com \
--cc=yuanchu@google.com \
--cc=yuzhao@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