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

[Mike Rapoport]

On Wed, Jul 22, 2026 at 08:04:04AM -0700, Song Liu wrote:
> 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?

Enabling ROX cache without using PMD_SIZE mappings is pure overhead without
advantage of using larger mappings for executable memory.
 
> Given this constraint, we can probably ship this now and do the rest in a
> follow up set.

Yeah, this is something to think more about :)
 
> For the set
> Acked-by: Song Liu <song@xxxxxxxxxx>

Thanks!

-- 
Sincerely yours,
Mike.