From: Michal Hocko <mhocko@suse.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
Peilin Ye <yepeilin@google.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
bpf@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org,
Meta kernel team <kernel-team@meta.com>
Subject: Re: [PATCH] memcg: skip cgroup_file_notify if spinning is not allowed
Date: Mon, 8 Sep 2025 11:28:20 +0200 [thread overview]
Message-ID: <aL6htMt-jHAaCGLv@tiehlicka> (raw)
In-Reply-To: <20250905201606.66198-1-shakeel.butt@linux.dev>
On Fri 05-09-25 13:16:06, Shakeel Butt wrote:
> Generally memcg charging is allowed from all the contexts including NMI
> where even spinning on spinlock can cause locking issues. However one
> call chain was missed during the addition of memcg charging from any
> context support. That is try_charge_memcg() -> memcg_memory_event() ->
> cgroup_file_notify().
>
> The possible function call tree under cgroup_file_notify() can acquire
> many different spin locks in spinning mode. Some of them are
> cgroup_file_kn_lock, kernfs_notify_lock, pool_workqeue's lock. So, let's
> just skip cgroup_file_notify() from memcg charging if the context does
> not allow spinning.
>
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> include/linux/memcontrol.h | 23 ++++++++++++++++-------
> mm/memcontrol.c | 7 ++++---
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 9dc5b52672a6..054fa34c936a 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -993,22 +993,25 @@ static inline void count_memcg_event_mm(struct mm_struct *mm,
> count_memcg_events_mm(mm, idx, 1);
> }
>
> -static inline void memcg_memory_event(struct mem_cgroup *memcg,
> - enum memcg_memory_event event)
> +static inline void __memcg_memory_event(struct mem_cgroup *memcg,
> + enum memcg_memory_event event,
> + bool allow_spinning)
> {
> bool swap_event = event == MEMCG_SWAP_HIGH || event == MEMCG_SWAP_MAX ||
> event == MEMCG_SWAP_FAIL;
>
> atomic_long_inc(&memcg->memory_events_local[event]);
Doesn't this involve locking on 32b? I guess we do not care all that
much but we might want to bail out early on those arches for
!allow_spinning
> - if (!swap_event)
> + if (!swap_event && allow_spinning)
> cgroup_file_notify(&memcg->events_local_file);
>
> do {
> atomic_long_inc(&memcg->memory_events[event]);
> - if (swap_event)
> - cgroup_file_notify(&memcg->swap_events_file);
> - else
> - cgroup_file_notify(&memcg->events_file);
> + if (allow_spinning) {
> + if (swap_event)
> + cgroup_file_notify(&memcg->swap_events_file);
> + else
> + cgroup_file_notify(&memcg->events_file);
> + }
>
> if (!cgroup_subsys_on_dfl(memory_cgrp_subsys))
> break;
> @@ -1018,6 +1021,12 @@ static inline void memcg_memory_event(struct mem_cgroup *memcg,
> !mem_cgroup_is_root(memcg));
> }
>
> +static inline void memcg_memory_event(struct mem_cgroup *memcg,
> + enum memcg_memory_event event)
> +{
> + __memcg_memory_event(memcg, event, true);
> +}
> +
> static inline void memcg_memory_event_mm(struct mm_struct *mm,
> enum memcg_memory_event event)
> {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 257d2c76b730..dd5cd9d352f3 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2306,12 +2306,13 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> bool drained = false;
> bool raised_max_event = false;
> unsigned long pflags;
> + bool allow_spinning = gfpflags_allow_spinning(gfp_mask);
>
> retry:
> if (consume_stock(memcg, nr_pages))
> return 0;
>
> - if (!gfpflags_allow_spinning(gfp_mask))
> + if (!allow_spinning)
> /* Avoid the refill and flush of the older stock */
> batch = nr_pages;
>
> @@ -2347,7 +2348,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> if (!gfpflags_allow_blocking(gfp_mask))
> goto nomem;
>
> - memcg_memory_event(mem_over_limit, MEMCG_MAX);
> + __memcg_memory_event(mem_over_limit, MEMCG_MAX, allow_spinning);
> raised_max_event = true;
>
> psi_memstall_enter(&pflags);
> @@ -2414,7 +2415,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> * a MEMCG_MAX event.
> */
> if (!raised_max_event)
> - memcg_memory_event(mem_over_limit, MEMCG_MAX);
> + __memcg_memory_event(mem_over_limit, MEMCG_MAX, allow_spinning);
>
> /*
> * The allocation either can't fail or will lead to more memory
> --
> 2.47.3
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2025-09-08 9:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 20:16 Shakeel Butt
2025-09-05 20:48 ` Peilin Ye
2025-09-05 21:33 ` Shakeel Butt
2025-09-05 21:40 ` Peilin Ye
2025-09-08 9:08 ` Michal Hocko
2025-09-08 17:11 ` Alexei Starovoitov
2025-09-09 6:20 ` Michal Hocko
2025-09-05 21:20 ` Roman Gushchin
2025-09-05 21:25 ` Tejun Heo
2025-09-05 21:35 ` Shakeel Butt
2025-09-05 21:31 ` Shakeel Butt
2025-09-05 21:42 ` Roman Gushchin
2025-09-05 21:50 ` Shakeel Butt
2025-09-05 22:44 ` Roman Gushchin
2025-09-08 9:28 ` Michal Hocko [this message]
2025-09-08 17:39 ` Shakeel Butt
2025-09-19 2:49 ` Shakeel Butt
2025-09-20 2:47 ` Alexei Starovoitov
2025-09-20 4:31 ` Shakeel Butt
2025-09-20 15:54 ` 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=aL6htMt-jHAaCGLv@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--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=memxor@gmail.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=tj@kernel.org \
--cc=yepeilin@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