From: Shakeel Butt <shakeel.butt@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Vlastimil Babka <vbabka@suse.cz>,
Alexei Starovoitov <ast@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
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 0/4] memcg: nmi-safe kmem charging
Date: Fri, 9 May 2025 20:11:55 -0700 [thread overview]
Message-ID: <xe443fcnpjf4nozjuzx2lzwjqkhzhkualcwxk4f5y6e5v7d7vl@h47t3oz3ippf> (raw)
In-Reply-To: <20250509182632.8ab2ba932ca5e0f867d21fc2@linux-foundation.org>
Hi Andrew,
On Fri, May 09, 2025 at 06:26:32PM -0700, Andrew Morton wrote:
> On Fri, 9 May 2025 16:28:55 -0700 Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> > BPF programs can trigger memcg charged kernel allocations in nmi
> > context. However memcg charging infra for kernel memory is not equipped
> > to handle nmi context. This series adds support for kernel memory
> > charging for nmi context.
>
> The patchset adds quite a bit of material to core MM on behalf of a
> single caller. So can we please take a close look at why BPF is doing
> this?
>
> What would be involved in changing BPF to avoid doing this, or of
> changing BPF to handle things locally? What would be the end-user
> impact of such an alteration? IOW, what is the value to our users of
> the present BPF behavior?
>
Before answering the questions, let me clarify that this series is
continuation of the work which added similar support for page allocator
and related memcg charging and now the work is happening for
kmalloc/slab allocations. Alexei has a proposal on reentrant kmalloc and
here I am providing how memcg charging for that (reentrant kmalloc)
should work.
Next let me take a stab in answering the questions and BPF folks can
correct me if I am wrong. From what I understand, users can attach BPF
programs at almost any place in kernel and those BPF programs can do
memory allocations. This line of work is to make those allocations work
if the any such BPF attach point is triggered in mni context.
Before this line of work (reentrant page and slab allocators), I think
BPF had its internal cache but it was very limited and can easily fail
allocation requests (please BPF folks correct me if I am wrong). This
was discussed in LSFMM this year as well.
Now regarding the impact to the users. First there will not be any
negative impact on the non-users of this feature. For the value this
feature will provide to users, I think this line of work will make BPF
programs of the users more reliable with better allocation behavior.
BPF folks, please add more comments for the value of these features.
thanks,
Shakeel
next prev parent reply other threads:[~2025-05-10 3:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 23:28 Shakeel Butt
2025-05-09 23:28 ` [PATCH 1/4] memcg: add infra for nmi safe memcg stats Shakeel Butt
2025-05-09 23:28 ` [PATCH 2/4] memcg: add nmi-safe update for MEMCG_KMEM Shakeel Butt
2025-05-09 23:28 ` [PATCH 3/4] memcg: nmi-safe slab stats updates Shakeel Butt
2025-05-09 23:28 ` [PATCH 4/4] memcg: make objcg charging nmi safe Shakeel Butt
2025-05-13 22:25 ` Alexei Starovoitov
2025-05-14 16:46 ` Shakeel Butt
2025-05-10 1:26 ` [PATCH 0/4] memcg: nmi-safe kmem charging Andrew Morton
2025-05-10 3:11 ` Shakeel Butt [this message]
2025-05-10 7:00 ` Harry Yoo
2025-05-12 14:52 ` Vlastimil Babka
2025-05-12 15:56 ` Vlastimil Babka
2025-05-12 19:12 ` Shakeel Butt
2025-05-13 7:15 ` Vlastimil Babka
2025-05-13 11:41 ` Peter Zijlstra
2025-05-13 22:17 ` Shakeel Butt
2025-05-14 7:11 ` Peter Zijlstra
2025-05-15 1:49 ` 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=xe443fcnpjf4nozjuzx2lzwjqkhzhkualcwxk4f5y6e5v7d7vl@h47t3oz3ippf \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--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