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

[Song Liu <song@kernel.org>]

Hi Thomas,

Thanks for your comments.

On Tue, Nov 29, 2022 at 2:23 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> 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.

I am not sure I fully understand your point here. Do you mean

1) There is something wrong with this solution, that makes it not suitable
for modules;
   or
2) The solution is in the right direction and it will very likely work
for modules.
But we haven't finished module support. ?

If it is 1), I would like to understand what are the issues that make it not
suitable for modules. If it is 2), I think a solid, mostly like working small
step toward the right direction is the better way as it makes code reviews
a lot easier and has much lower risks. Does this make sense?

I would also highlight that part of the benefit of this work comes from
reducing direct map fragmentations. While BPF programs consume less
memory, they are more dynamic and can cause more direct map
fragmentations. bpf_prog_pack in upstream kernel already covers this
part, but this set is a better solution than bpf_prog_pack.

Finally, I would like to point out that 5/6 and 6/6 of (v5) the set let BPF
programs share a 2MB page with static kernel text. Therefore, even
for systems without many BPF programs, we should already see some
reduction in iTLB misses.

Thanks,
Song