From: Mike Rapoport <rppt@kernel.org>
To: Song Liu <song@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Daniel Borkmann <daniel@iogearbox.net>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eduard Zingerman <eddyz87@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Jiri Olsa <jolsa@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
"H. Peter Anvin" <hpa@zytor.com>,
Yonghong Song <yonghong.song@linux.dev>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org
Subject: Re: [PATCH bpf-next v3 0/5] bpf, x86: enable EXECMEM_ROX_CACHE for BPF allocations
Date: Wed, 22 Jul 2026 11:05:47 +0300 [thread overview]
Message-ID: <amB52yECfXNgbeY4@kernel.org> (raw)
In-Reply-To: <CAPhsuW6+6zcSRGUAtp=3e4a8at3yuRP8Xijb-4LBHtQ8Li6wrQ@mail.gmail.com>
On Tue, Jul 21, 2026 at 10:59:06AM -0700, Song Liu wrote:
> On Sun, Jul 19, 2026 at 2:23 AM Mike Rapoport <rppt@kernel.org> wrote:
> > > >
> > > > Since commit c82be0be9576 ("mm: vmalloc: don't account for number of nodes
> > > > for HUGE_VMAP allocations") vmalloc_huge() is fine with PMD_SIZE regardless
> > > > of number of nodes.
> > >
> > > Before execmem can handle sub page allocations, how about we
> > > send allocations that are bigger than page size directly to execmem,
> > > and let bpf_prog_pack handle sub page allocations. Then,
> > > BPF_PROG_PACK_SIZE will be PAGE_SIZE. This should be a net
> > > win for x86_64. Other archs will be the same. WDYT?
> >
> > Makes perfect sense to me for x86.
>
> Can we include this change to this patch set? This will make this
> change a meaningful step towards migrating to EXECMEM.
I'd prefer to leave this as a separate followup.
The decision whether to use EXECMEM_ROX_CACHE is made at runtime, which
means that BPF_PROG_PACK_SIZE should become a variable, that variable needs
initialization at some point during boot and that in turn requires a new
helper in execmem that will say if EXECMEM_CACHE_ROX is enabled.
> > On architectures that support large mappings in the direct map and do not
> > support EXECMEM_CACHE_ROX this will increase direct map fragmentation.
>
> Architectures that support bpf_prog_pack can benefit from
> EXECMEM_CACHE_ROX. What does it take to also enable
> EXECMEM_CACHE_ROX for them?
For EXECMEM_ROX_CACHE to help in reducing the fragmentation and TLB
pressure an architecture should support collapsing of the split mappings at
least in vmalloc/modules space.
There is an RFC for arm64 to add support for EXECMEM_ROX_CACHE there:
https://lore.kernel.org/all/20260611130144.1385343-1-abarnas@google.com
and it looks like it'll take a couple of iterations :)
I don't how much work it would be for other architectures.
> Thanks,
> Song
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-07-22 8:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 7:51 [PATCH bpf-next v3 0/5] bpf, x86: enable EXECMEM_ROX_CACHE for BPF allocations Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 1/5] bpf: dispatcher: allocate bpf_dispatcher->rw_image with vzalloc() Mike Rapoport (Microsoft)
2026-07-16 8:52 ` bot+bpf-ci
2026-07-16 9:27 ` Mike Rapoport
2026-07-16 9:49 ` Kumar Kartikeya Dwivedi
2026-07-16 7:51 ` [PATCH bpf-next v3 2/5] bpf: drop __weak from bpf_jit_alloc_exec() and bpf_jit_free_exec() Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 3/5] bpf: alloc_prog_pack(): skip ROX management for already ROX memory Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 4/5] bpf, x86: make sure allocation in arch_bpf_trampoline_size() is writable Mike Rapoport (Microsoft)
2026-07-16 7:51 ` [PATCH bpf-next v3 5/5] x86/bpf: enable EXECMEM_ROX_CACHE for BPF allocations Mike Rapoport (Microsoft)
2026-07-17 0:00 ` [PATCH bpf-next v3 0/5] bpf, x86: " Song Liu
2026-07-17 6:41 ` Mike Rapoport
2026-07-17 7:27 ` Song Liu
2026-07-17 9:29 ` Mike Rapoport
2026-07-17 17:50 ` Song Liu
2026-07-19 9:23 ` Mike Rapoport
2026-07-21 17:59 ` Song Liu
2026-07-22 8:05 ` Mike Rapoport [this message]
2026-07-22 15:04 ` Song Liu
2026-07-27 8:35 ` Mike Rapoport
2026-07-22 15:40 ` patchwork-bot+netdevbpf
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=amB52yECfXNgbeY4@kernel.org \
--to=rppt@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=hpa@zytor.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=song@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=yonghong.song@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 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.