Re: [PATCH bpf-next v3 0/5] bpf, x86: enable EXECMEM_ROX_CACHE for BPF allocations

[Song Liu]

On Wed, Jul 22, 2026 at 1:06 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxx> 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.

Hmm... deciding whether to use EXECMEM_ROX_CACHE at runtime seems
weird. Can we enable it all the time and decide how much memory it reserves
at runtime?

Given this constraint, we can probably ship this now and do the rest in a
follow up set.

For the set
Acked-by: Song Liu <song@xxxxxxxxxx>

> > > 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?
[...]