Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20220128234517.3503701-1-song@kernel.org> <20220128234517.3503701-8-song@kernel.org>
 <ab7e0a98-fced-23b3-6876-01ce711bd579@iogearbox.net>
In-Reply-To: <ab7e0a98-fced-23b3-6876-01ce711bd579@iogearbox.net>
From:   Song Liu <song@kernel.org>
Date:   Mon, 31 Jan 2022 17:34:46 -0800
Message-ID: <CAPhsuW5Pfvn8GNfuuuEGzdyugGDLF_g-V3T7RihBrxoQLxNb5g@mail.gmail.com>
Subject: Re: [PATCH v7 bpf-next 7/9] bpf: introduce bpf_prog_pack allocator
To:     Daniel Borkmann <daniel@iogearbox.net>
Cc:     bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Andrii Nakryiko <andrii@kernel.org>,
        Kernel Team <kernel-team@fb.com>,
        Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
        Ilya Leoshkevich <iii@linux.ibm.com>,
        Nicholas Piggin <npiggin@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 31, 2022 at 4:06 PM Daniel Borkmann <daniel@iogearbox.net> 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@kernel.org>
> > ---
> >   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