On Mon, Jan 31, 2022 at 4:06 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
>
> On 1/29/22 12:45 AM, Song Liu wrote:
> > Most BPF programs are small, but they consume a page each. For systems
> > with busy traffic and many BPF programs, this could add significant
> > pressure to instruction TLB.
> >
> > Introduce bpf_prog_pack allocator to pack multiple BPF programs in a huge
> > page. The memory is then allocated in 64 byte chunks.
> >
> > Memory allocated by bpf_prog_pack allocator is RO protected after initial
> > allocation. To write to it, the user (jit engine) need to use text poke
> > API.
>
> Did you benchmark the program load times under this API, e.g. how much
> overhead is expected for very large programs?
For the two scale tests in test_verifier:
./test_verifier 965 966
#965/p scale: scale test 1 OK
#966/p scale: scale test 2 OK
The runtime is about 0.6 second before the set and 0.7 second after.
Is this a good benchmark?
>
> > Signed-off-by: Song Liu <song@xxxxxxxxxx>
> > ---
> > kernel/bpf/core.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 127 insertions(+)
> >
[...]
> > + }
> > + mutex_lock(&pack_mutex);
> > + list_for_each_entry(pack, &pack_list, list) {
> > + pos = bitmap_find_next_zero_area(pack->bitmap, BPF_PROG_CHUNK_COUNT, 0,
> > + nbits, 0);
> > + if (pos < BPF_PROG_CHUNK_COUNT)
> > + goto found_free_area;
> > + }
> > +
> > + pack = alloc_new_pack();
> > + if (!pack)
> > + goto out;
>
> Will this effectively disable the JIT for all bpf_prog_pack_alloc requests <=
> BPF_PROG_MAX_PACK_PROG_SIZE when vmap_allow_huge is false (e.g. boot param via
> nohugevmalloc) ?
This won't disable JIT. It will just allocate 512x 4k pages for a 2MB pack. We
will mark the whole 2MB RO, same as a 2MB huge page. We still benefit
from this as this avoids poking the linear mapping (1GB pages) to 4kB pages
with set_memory_ro().
Thanks,
Song
