From: Michal Hocko <mhocko@suse.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, andrii@kernel.org, memxor@gmail.com,
akpm@linux-foundation.org, peterz@infradead.org, vbabka@suse.cz,
bigeasy@linutronix.de, rostedt@goodmis.org, houtao1@huawei.com,
hannes@cmpxchg.org, shakeel.butt@linux.dev, willy@infradead.org,
tglx@linutronix.de, jannh@google.com, tj@kernel.org,
linux-mm@kvack.org, kernel-team@fb.com
Subject: Re: [PATCH bpf-next v4 4/6] memcg: Use trylock to access memcg stock_lock.
Date: Tue, 14 Jan 2025 11:39:29 +0100 [thread overview]
Message-ID: <Z4Y-4fkNQJFMEPwh@tiehlicka> (raw)
In-Reply-To: <20250114021922.92609-5-alexei.starovoitov@gmail.com>
On Mon 13-01-25 18:19:20, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
>
> Teach memcg to operate under trylock conditions when
> spinning locks cannot be used.
> The end result is __memcg_kmem_charge_page() and
> __memcg_kmem_uncharge_page() are safe to use from
> any context in RT and !RT.
> In !RT the NMI handler may fail to trylock stock_lock.
> In RT hard IRQ and NMI handlers will not attempt to trylock.
I believe this is local_trylock_irqsave specific thing that is not that
interesting for the particular code path. It is more useful to mention
consequences. I would phrase it this way.
local_trylock might fail and this would lead to charge cache bypass if
the calling context doesn't allow spinning (gfpflags_allow_spinning).
In those cases we try to charge the memcg counter directly and fail
early if that is not possible. This might cause a pre-mature charge
failing but it will allow an opportunistic charging that is safe from
try_alloc_pages path.
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> mm/memcontrol.c | 24 ++++++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 7b3503d12aaf..e4c7049465e0 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1756,7 +1756,8 @@ static bool obj_stock_flush_required(struct memcg_stock_pcp *stock,
> *
> * returns true if successful, false otherwise.
> */
> -static bool consume_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
> +static bool consume_stock(struct mem_cgroup *memcg, unsigned int nr_pages,
> + gfp_t gfp_mask)
> {
> struct memcg_stock_pcp *stock;
> unsigned int stock_pages;
> @@ -1766,7 +1767,11 @@ static bool consume_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
> if (nr_pages > MEMCG_CHARGE_BATCH)
> return ret;
>
> - local_lock_irqsave(&memcg_stock.stock_lock, flags);
> + if (!local_trylock_irqsave(&memcg_stock.stock_lock, flags)) {
> + if (!gfpflags_allow_spinning(gfp_mask))
> + return ret;
> + local_lock_irqsave(&memcg_stock.stock_lock, flags);
> + }
>
> stock = this_cpu_ptr(&memcg_stock);
> stock_pages = READ_ONCE(stock->nr_pages);
> @@ -1851,7 +1856,14 @@ static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
> {
> unsigned long flags;
>
> - local_lock_irqsave(&memcg_stock.stock_lock, flags);
> + if (!local_trylock_irqsave(&memcg_stock.stock_lock, flags)) {
> + /*
> + * In case of unlikely failure to lock percpu stock_lock
> + * uncharge memcg directly.
> + */
> + mem_cgroup_cancel_charge(memcg, nr_pages);
> + return;
> + }
> __refill_stock(memcg, nr_pages);
> local_unlock_irqrestore(&memcg_stock.stock_lock, flags);
> }
> @@ -2196,9 +2208,13 @@ int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> unsigned long pflags;
>
> retry:
> - if (consume_stock(memcg, nr_pages))
> + if (consume_stock(memcg, nr_pages, gfp_mask))
> return 0;
>
> + if (!gfpflags_allow_spinning(gfp_mask))
> + /* Avoid the refill and flush of the older stock */
> + batch = nr_pages;
> +
> if (!do_memsw_account() ||
> page_counter_try_charge(&memcg->memsw, batch, &counter)) {
> if (page_counter_try_charge(&memcg->memory, batch, &counter))
> --
> 2.43.5
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2025-01-14 10:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 2:19 [PATCH bpf-next v4 0/6] bpf, mm: Introduce try_alloc_pages() Alexei Starovoitov
2025-01-14 2:19 ` [PATCH bpf-next v4 1/6] mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation Alexei Starovoitov
2025-01-14 9:53 ` Peter Zijlstra
2025-01-14 10:19 ` Michal Hocko
2025-01-14 10:39 ` Peter Zijlstra
2025-01-14 10:43 ` Michal Hocko
2025-01-14 18:29 ` Alexei Starovoitov
2025-01-14 18:34 ` Steven Rostedt
2025-01-14 10:31 ` Michal Hocko
2025-01-15 1:23 ` Alexei Starovoitov
2025-01-15 8:35 ` Michal Hocko
2025-01-15 22:33 ` Alexei Starovoitov
2025-01-14 2:19 ` [PATCH bpf-next v4 2/6] mm, bpf: Introduce free_pages_nolock() Alexei Starovoitov
2025-01-14 2:19 ` [PATCH bpf-next v4 3/6] locking/local_lock: Introduce local_trylock_irqsave() Alexei Starovoitov
2025-01-14 2:19 ` [PATCH bpf-next v4 4/6] memcg: Use trylock to access memcg stock_lock Alexei Starovoitov
2025-01-14 10:39 ` Michal Hocko [this message]
2025-01-14 2:19 ` [PATCH bpf-next v4 5/6] mm, bpf: Use memcg in try_alloc_pages() Alexei Starovoitov
2025-01-14 2:19 ` [PATCH bpf-next v4 6/6] bpf: Use try_alloc_pages() to allocate pages for bpf needs Alexei Starovoitov
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=Z4Y-4fkNQJFMEPwh@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=bpf@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=houtao1@huawei.com \
--cc=jannh@google.com \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=memxor@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shakeel.butt@linux.dev \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.