linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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