linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: jingxiang zeng <jingxiangzeng.cas@gmail.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>,
	Jingxiang Zeng <linuszeng@tencent.com>,
	linux-mm@kvack.org,  akpm@linux-foundation.org,
	mhocko@kernel.org, roman.gushchin@linux.dev,
	 muchun.song@linux.dev, chengming.zhou@linux.dev,
	kasong@tencent.com,  kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] mm/list_lru: make the case where mlru is NULL as unlikely
Date: Wed, 26 Feb 2025 10:09:42 +0800	[thread overview]
Message-ID: <CAJqJ8iiTYu6=96YcPvLrJ2m8CsooVNsjkqF8Kaaf4mmBOEoX9Q@mail.gmail.com> (raw)
In-Reply-To: <20250226011147.GB1500140@cmpxchg.org>

On Wed, 26 Feb 2025 at 09:12, Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> On Tue, Feb 25, 2025 at 08:23:12AM -0800, Shakeel Butt wrote:
> > On Tue, Feb 25, 2025 at 11:30:20PM +0800, Jingxiang Zeng wrote:
> > > From: Zeng Jingxiang <linuszeng@tencent.com>
> > >
> > > In the following memcg_list_lru_alloc() function, mlru here is almost
> > > always NULL, so in most cases this should save a function call, mark
> > > mlru as unlikely to optimize the code.
> > >         do {
> > >                 xas_lock_irqsave(&xas, flags);
> > >                 if (!xas_load(&xas) && !css_is_dying(&pos->css)) {
> > >                         xas_store(&xas, mlru);
> > >                         if (!xas_error(&xas))
> > >                                 mlru = NULL;
> > >                 }
> > >                 xas_unlock_irqrestore(&xas, flags);
> > >         } while (xas_nomem(&xas, GFP_KERNEL));
> > > >       if (mlru)
> > >                 kfree(mlru);
> > >
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202412290924.UTP7GH2Z-lkp@intel.com/
> > > Signed-off-by: Zeng Jingxiang <linuszeng@tencent.com>
> > > ---
> > >  mm/list_lru.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/mm/list_lru.c b/mm/list_lru.c
> > > index 064d2018e265..e7e13513ff8e 100644
> > > --- a/mm/list_lru.c
> > > +++ b/mm/list_lru.c
> > > @@ -552,7 +552,7 @@ static int memcg_list_lru_alloc(struct mem_cgroup *memcg, struct list_lru *lru)
> > >                     }
> > >                     xas_unlock_irqrestore(&xas, flags);
> > >             } while (xas_nomem(&xas, GFP_KERNEL));
> > > -           if (mlru)
> > > +           if (unlikely(mlru))
> > >                     kfree(mlru);
> >
> > The report is saying not to check at all. So, just remove the check and
> > simply call kfree(mlru) as it handles the NULL check efficiently.
>
> I actually like it in this case. It's an "active comment" that this
> only happens in the failure case and we don't routinely free here.
>
> That said, does it have to free the mlru inside the loop at all? If
> the tree insertion fails, why not reuse it for the next attempt?

I agree with this implementation; reusing the mlru for the next attempt
when the tree insertion fails is more appropriate.
>
> diff --git a/mm/list_lru.c b/mm/list_lru.c
> index 7d69434c70e0..490473af3122 100644
> --- a/mm/list_lru.c
> +++ b/mm/list_lru.c
> @@ -510,7 +510,7 @@ int memcg_list_lru_alloc(struct mem_cgroup *memcg, struct list_lru *lru,
>                          gfp_t gfp)
>  {
>         unsigned long flags;
> -       struct list_lru_memcg *mlru;
> +       struct list_lru_memcg *mlru = NULL;
>         struct mem_cgroup *pos, *parent;
>         XA_STATE(xas, &lru->xa, 0);
>
> @@ -535,9 +535,11 @@ int memcg_list_lru_alloc(struct mem_cgroup *memcg, struct list_lru *lru,
>                         parent = parent_mem_cgroup(pos);
>                 }
>
> -               mlru = memcg_init_list_lru_one(lru, gfp);
> -               if (!mlru)
> -                       return -ENOMEM;
> +               if (!mlru) {
> +                       mlru = memcg_init_list_lru_one(lru, gfp);
> +                       if (!mlru)
> +                               return -ENOMEM;
> +               }
>                 xas_set(&xas, pos->kmemcg_id);
>                 do {
>                         xas_lock_irqsave(&xas, flags);
> @@ -548,10 +550,11 @@ int memcg_list_lru_alloc(struct mem_cgroup *memcg, struct list_lru *lru,
>                         }
>                         xas_unlock_irqrestore(&xas, flags);
>                 } while (xas_nomem(&xas, gfp));
> -               if (mlru)
> -                       kfree(mlru);
>         } while (pos != memcg && !css_is_dying(&pos->css));
>
> +       if (unlikely(mlru))
> +               kfree(mlru);
> +
>         return xas_error(&xas);
>  }
>  #else
>


  reply	other threads:[~2025-02-26  2:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-25 15:30 Jingxiang Zeng
2025-02-25 16:23 ` Shakeel Butt
2025-02-26  1:11   ` Johannes Weiner
2025-02-26  2:09     ` jingxiang zeng [this message]
2025-02-26 21:08     ` Shakeel Butt
2025-02-27  8:03       ` jingxiang zeng
2025-02-28 16:30   ` Vlastimil Babka
2025-02-28 16:33     ` Vlastimil Babka
2025-02-28 18:48       ` Shakeel Butt

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='CAJqJ8iiTYu6=96YcPvLrJ2m8CsooVNsjkqF8Kaaf4mmBOEoX9Q@mail.gmail.com' \
    --to=jingxiangzeng.cas@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linuszeng@tencent.com \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    /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