Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs

[Song Liu <song@kernel.org>]

On Mon, Nov 7, 2022 at 3:39 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Mon, Nov 07, 2022 at 03:13:59PM -0800, Song Liu wrote:
> > The benchmark used here is identical on our web service, which runs on
> > many many servers, so it represents the workload that we care a lot.
> > Unfortunately, it is not possible to run it out of our data centers.
>
> I am not asking for that, I am asking for you to pick any similar
> benchark which can run in paralellel which may yield similar results.
>
> > We can build some artificial workloads and probably get much higher
> > performance improvements. But these workload may not represent real
> > world use cases.
>
> You can very likely use some existing benchmark.
>
> The direct map fragmentation stuff doesn't require much effort, as
> was demonstrated by Aaron, you can easily do that or more by
> running all selftests or just the test_bpf. This I buy.
>
> I'm not buying the iTLB gains as I can't even reproduce them myself for
> eBPF JIT, but I tested against iTLB when using eBPF JIT, perhaps you
> mean iTLB gains for other memory intensive applications running in
> tandem?

Right. In most of the cases, BPF programs are not the main workload.
The main workloads are user space services with big .text sections.
We measure performance in terms of main service throughput under
some latency requirements. For benchmarks with small .text sections,
the benefit from iTLB gains is not significant.

>
> And none of your patches mentions the gains of this effort helping
> with the long term advantage of centralizing the semantics for
> permissions on memory.

Right.. I will add that.

Thanks,
Song