Re: [PATCH bpf-next] libbpf: improve BTF dedup handling of "identical" BTF types

[Alan Maguire <alan.maguire@oracle.com>]

On 05/05/2025 22:10, Andrii Nakryiko wrote:
> On Fri, May 2, 2025 at 11:09 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Fri, May 2, 2025 at 2:32 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>>>
>>>>
>>>> On the other hand, this seems to help to reduce duplication across many
>>>> kernel modules. In my local test, I had 639 kernel module built. Overall
>>>> .BTF sections size goes down from 41MB bytes down to 5MB (!), which is
>>>> pretty impressive for such a straightforward piece of logic added. But
>>>> it would be nice to validate independently just in case my bash and
>>>> Python-fu is broken.
>>>>
>>>> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>>>
>>> Looks great!
>>>
>>> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
>>>
>>> Should have some numbers on the module size differences with this change
>>> by Monday, had to dash before my build completed.
>>
>> I'm curious what BTF sizes you'll see.
>>
>> Sounds like dwarf has more cases of "same type but different id"
>> than we expected.
>> So existing workarounds are working only because we have very
>> few modules that rely on proper dedup of kernel types.
>> Beyond array/struct/ptrs, I wonder, what else is there.
> 
> Well, turns out I screwed up the measurements. I thought that I used
> libbpf version with Alan's patch applied as a baseline, but it turned
> out it was libbpf without his patch. So all the measurements (41MB ->
> 5MB) are actually due to Alan's identical pointers fix. My patches
> have no effect on module BTF sizes (which is good and a bit more
> sensible, I should have double checked before submitting). So, if we
> are going to apply the patch, it's probably better to just drop that
> paragraph. Or I can send v2 with an adjusted commit message, whatever
> is better.
> 

I did see some small changes, so the fact that you've added additional
cases here definitely helps; with ~3000 modules built I got ~50Mb of
module BTF in total both before and after the change, but comparing the
results using latest pahole (with the pointer-specific fix) and your
change (the more general fix) we do see some size reductions:

$ find . -name '*.ko' -print |sort|xargs objdump -h --section=".BTF" >
/tmp/modout.base
$ awk '/file format/ { printf $1" " } / .BTF/ { print strtonum("0x" $3)
}'  /tmp/modout.base > /tmp/modout.base.sizes
# rebuild pahole with Andrii's change
$ rm vmlinux
$ make -j$(nproc)
$ find . -name '*.ko' -print |sort|xargs objdump -h --section=".BTF" >
/tmp/modout.test
$ awk '/file format/ { printf $1" " } /tmp/modout.test / .BTF/ { print
strtonum("0x" $3) }' > /tmp/modout.test.sizes

$ diff /tmp/modout.base.sizes /tmp/modout.test.sizes
198c198
< ./drivers/char/ipmi/ipmi_si.ko: 11575
---
> ./drivers/char/ipmi/ipmi_si.ko: 11539
1810c1810
< ./drivers/platform/x86/ideapad-laptop.ko: 7122
---
> ./drivers/platform/x86/ideapad-laptop.ko: 7086
1952c1952
< ./drivers/scsi/mpi3mr/mpi3mr.ko: 52625
---
> ./drivers/scsi/mpi3mr/mpi3mr.ko: 52589

So while numerically it isn't huge, it definitely validates the
principle of making the identical type handling less specific to the
cases we had encountered. If you want to resync libbpf github again I
can update the submodule commit in pahole. Thanks!

Alan