From: Johannes Weiner <hannes@cmpxchg.org>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: 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: Tue, 25 Feb 2025 20:11:47 -0500 [thread overview]
Message-ID: <20250226011147.GB1500140@cmpxchg.org> (raw)
In-Reply-To: <ngowzrpvvfklkyswlcg7x6gfiqjhxaankkx3jgo3pmvrbzbzdv@jqwfqbjxxvv3>
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?
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
next prev parent reply other threads:[~2025-02-26 1:12 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 [this message]
2025-02-26 2:09 ` jingxiang zeng
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=20250226011147.GB1500140@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--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