Re: [PATCH bpf-next 0/5] bpf: Expose pinned arenas as sized bpffs files

[Andrea Righi <arighi@nvidia.com>]

On Sun, Oct 18, 2026 at 12:52:46AM +0000, Alexei Starovoitov wrote:
> On Fri, Oct 16, 2026 at 12:52 PM Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> > kernel to do that. But once we have the ability to create ARRAY from a
> > bunch of pre-existing memory (e.g., from memfd), this can be used both
> > in a guest and in the host, and both models, guest allocates or host
> > allocates, could be supported with the same model.
> 
> I don't think it will work for their use case.
> With array of maps scx needs two lookups and two NULL checks
> on every access, and the result cannot be kept in the task ctx
> which is in arena today, since ptr_to_map_value becomes scalar.
> unless everything is converted to magically bounded array, but...

Agreed, from a sched_ext perspective, arena is really what we need. Most
of the new schedulers already keep their per-task and per-CPU state in
the arena, and an idea could be to link that state directly to the
shared hints, e.g., keep a pointer to the vCPU's hint slot in the
per-CPU context and dereference it in the hot paths, without any lookup.

Andrii, about the 4G / single arena limitation: for this use case I
don't think it's not a concern, the shared part is a few pages per vCPU.
Having the shared pages in the same arena as the rest of the scheduler
state is exactly the property we want.

Thanks,
-Andrea