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

[Mike Rapoport]

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.
 
> > 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@xxxxxxxxxx

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.