From: Shakeel Butt <shakeel.butt@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org,
Meta kernel team <kernel-team@meta.com>,
bpf@vger.kernel.org
Subject: Re: [PATCH 1/4] memcg: simplify consume_stock
Date: Tue, 29 Apr 2025 21:37:26 -0700 [thread overview]
Message-ID: <ik3yjjt6evxexkaculyiibgrgxtvimwx7rzalpbecb75gpmmck@pcsmy6kxzynb> (raw)
In-Reply-To: <dvyyqubghf67b3qsuoreegqk4qnuuqfkk7plpfhhrck5yeeuic@xbn4c6c7yc42>
On Tue, Apr 29, 2025 at 04:51:03PM -0700, Alexei Starovoitov wrote:
> On Tue, Apr 29, 2025 at 04:04:25PM -0700, Shakeel Butt wrote:
> > The consume_stock() does not need to check gfp_mask for spinning and can
> > simply trylock the local lock to decide to proceed or fail. No need to
> > spin at all for local lock.
> >
> > Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
> > ---
> > mm/memcontrol.c | 20 +++++++-------------
> > 1 file changed, 7 insertions(+), 13 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 650fe4314c39..40d0838d88bc 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -1804,16 +1804,14 @@ static bool obj_stock_flush_required(struct memcg_stock_pcp *stock,
> > * consume_stock: Try to consume stocked charge on this cpu.
> > * @memcg: memcg to consume from.
> > * @nr_pages: how many pages to charge.
> > - * @gfp_mask: allocation mask.
> > *
> > - * The charges will only happen if @memcg matches the current cpu's memcg
> > - * stock, and at least @nr_pages are available in that stock. Failure to
> > - * service an allocation will refill the stock.
> > + * Consume the cached charge if enough nr_pages are present otherwise return
> > + * failure. Also return failure for charge request larger than
> > + * MEMCG_CHARGE_BATCH or if the local lock is already taken.
> > *
> > * returns true if successful, false otherwise.
> > */
> > -static bool consume_stock(struct mem_cgroup *memcg, unsigned int nr_pages,
> > - gfp_t gfp_mask)
> > +static bool consume_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
> > {
> > struct memcg_stock_pcp *stock;
> > uint8_t stock_pages;
> > @@ -1821,12 +1819,8 @@ static bool consume_stock(struct mem_cgroup *memcg, unsigned int nr_pages,
> > bool ret = false;
> > int i;
> >
> > - if (nr_pages > MEMCG_CHARGE_BATCH)
> > - return ret;
> > -
> > - if (gfpflags_allow_spinning(gfp_mask))
> > - local_lock_irqsave(&memcg_stock.stock_lock, flags);
> > - else if (!local_trylock_irqsave(&memcg_stock.stock_lock, flags))
> > + if (nr_pages > MEMCG_CHARGE_BATCH ||
> > + !local_trylock_irqsave(&memcg_stock.stock_lock, flags))
>
> I don't think it's a good idea.
> spin_trylock() will fail often enough in PREEMPT_RT.
> Even during normal boot I see preemption between tasks and they
> contend on the same cpu for the same local_lock==spin_lock.
> Making them take slow path is a significant behavior change
> that needs to be carefully considered.
I didn't really think too much about PREEMPT_RT kernels as I assume
performance is not top priority but I think I get your point. Let me
explain and correct me if I am wrong. On PREEMPT_RT kernel, the local
lock is a spin lock which is actually a mutex but with priority
inheritance. A task having the local lock can still get context switched
(but will remain on same CPU run queue) and the newer task can try to
acquire the memcg stock local lock. If we just do trylock, it will
always go to the slow path but if we do local_lock() then it will sleeps
and possibly gives its priority to the task owning the lock and possibly
make that task to get the CPU. Later the task slept on memcg stock lock
will wake up and go through fast path.
Ok, I will drop the first patch. Please let me know your comments on the
remaining series.
>
> Also please cc bpf@vger in the future for these kind of changes.
Sounds good.
next prev parent reply other threads:[~2025-04-30 4:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 23:04 [PATCH 0/4] memcg: decouple memcg and objcg stocks Shakeel Butt
2025-04-29 23:04 ` [PATCH 1/4] memcg: simplify consume_stock Shakeel Butt
2025-04-29 23:51 ` Alexei Starovoitov
2025-04-30 4:37 ` Shakeel Butt [this message]
2025-04-30 15:11 ` Sebastian Andrzej Siewior
2025-04-29 23:04 ` [PATCH 2/4] memcg: separate local_trylock for memcg and obj Shakeel Butt
2025-04-30 11:42 ` Vlastimil Babka
2025-04-30 15:03 ` Shakeel Butt
2025-04-29 23:04 ` [PATCH 3/4] memcg: completely decouple memcg and obj stocks Shakeel Butt
2025-04-30 12:21 ` Vlastimil Babka
2025-04-29 23:04 ` [PATCH 4/4] memcg: no irq disable for memcg stock lock Shakeel Butt
2025-04-30 12:26 ` Vlastimil Babka
2025-05-06 22:55 [PATCH v3 0/4] memcg: decouple memcg and objcg stocks Shakeel Butt
2025-05-06 22:55 ` [PATCH 1/4] memcg: simplify consume_stock Shakeel Butt
2025-05-07 11:43 ` Vlastimil Babka
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=ik3yjjt6evxexkaculyiibgrgxtvimwx7rzalpbecb75gpmmck@pcsmy6kxzynb \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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