markrwilliams
33 minutes ago
Skip the first half of the article to learn how the project overcame eBPF programs' limited runtime environment:
"On Linux 6.9 and newer (6.10 on arm64, where JIT support for the arena landed later), the window is backed by bpf_arena... On kernels without a usable arena, the same four gigabytes are assembled from 4-MiB pieces... [in] separate global-data maps."
These maps are of type BPF_MAP_TYPE_ARRAY.
See https://lwn.net/Articles/961941/ for a discussion of `bpf_arena`.
ayles
22 minutes ago
And compatibility part was most fun =)
Basically, it is better to use maps that can be directly used with load with immediate map index/fd, but we have at most 64 of those, sharing limit with user's data maps and even maps used for (iirc) 7.1 gotox. So for most programs we just use 32 maps or so. If we need more memory - only then array maps (I mean one that has more than 1 element and each element is 4MB) are used as upper part of address space, since they require helper call and are overall slower for our case. But fiber stacks can be allocated from this "slow space", because fiber mostly never reloads its map pointer and fiber stack is aligned so it is always within one such region. (and that is one part of two - memory; second one is about compute and verifier limits and we overcome them by using regions and dispatch-loop)