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

[Thomas Gleixner <tglx@linutronix.de>]

On Mon, Nov 14 2022 at 17:30, Song Liu wrote:
> On Mon, Nov 7, 2022 at 2:41 PM Song Liu <song@kernel.org> wrote:
> Currently, I have got the following action items for v3:
> 1. Add unify API to allocate text memory to motivation;
> 2. Update Documentation/x86/x86_64/mm.rst;
> 3. Allow none PMD_SIZE allocation for powerpc.
>
> 1 and 2 are relatively simple. We can probably do 3 in a follow up patch
> (as I don't have powerpc environments for testing). Did I miss anything?
>
> Besides these, does this set look reasonable? Andrew and Peter, could
> you please share your comments on this?

This is a step into the right direction, but is it a solution which has
a broader benefit? I don't think so.

While you are so concerned about (i)TLB usage for BPF, I'm way more
concerned about modules. Just from a random server class workstation:

Total module memory:	12.4609 MB
Number of 4k PTEs:         3190

The above would nicely fit into 7 or 8 2M mappings.

Guess how much memory is occupied by BPF on that machine and how much
BPF contributes to iTLB pressure? In comparison to the above very close
to zero.

Modules have exactly the same problem as BPF, just an order of magnitude
larger.

So we don't need a "works" for BPF solution which comes with the
handwaving assumption that it could be used for modules too. We need
something which demonstrates that it solves the entire problem class.

Modules are the obvious starting point. Once that is solved pretty much
everything else falls into place including BPF.

Without modules support this whole exercise is pointless and not going
anywhere near x86.

Thanks,

        tglx