Re: ppc64le vmlinuz is huge when building with BTF

[Dominique Martinet <asmadeus@codewreck.org>]

Alan Maguire wrote on Thu, Jun 15, 2023 at 03:31:49PM +0100:
> However the problem I suspect is this:
> 
>  51 .debug_info   0a488b55  0000000000000000  0000000000000000  026f8d20
>  2**0
>                   CONTENTS, READONLY, DEBUGGING
> [...]
> 
> The debug info hasn't been stripped, so I suspect the packaging spec
> file or equivalent - in perhaps trying to preserve the .BTF section -
> is preserving debug info too. DWARF needs to be there at BTF
> generation time in vmlinux but is usually stripped for non-debug
> packages.

Thanks Alan and Eduard!
I guess I should have checked that first, it helps.

We're not stripping anything in vmlinuz for other archs -- the linker
script already should be including only the bare minimum to decompress
itself (+compressed useful bits), so I guess it's a Kbuild issue for the
arch.
We can add a strip but I unfortunately have no way of testing ppc build,
I'll ask around the build linux-kbuild and linuxppc-dev lists if that's
expected; it shouldn't be that bad now that's figured out.


> FYI we're aiming to make BTF module-loadable via CONFIG_DEBUG_INFO_BTF=m
> in the future, I'm hoping to get an RFC patch out for that soon once
> other BTF-related issues are sorted. Hope this helps

Oh, that's interesting -- I assume that'll only change the 'built-in'
BTF info? Or will that also split BTF info in other modules as
e.g. modfoo_btf.ko?
For x86_64 the size increase of vmlinuz itself is rather acceptable
(<2MB), but the sheer amount of modules (the -lts package has over 3k
modules...) means that even a small size increase for each module ends
up taking proportionally a high amount of space (+20MB from 90MB), so
being able to package separately would be appreciated (alpine likes
splitting optional features in subpackages)
Packaging-wise I'm not sure it'd make sense to keep the overhead in
other modules and just split the 'main' btf infos.

Otoh even if it doesn't help with packaging, having a smaller vmlinuz
means faster boot and lower kernel memory footprint (I think *2?) for
people who don't need it, so I think it's a good idea and we'll probably
enable it once it becomes available. Thanks for the heads up!

-- 
Dominique Martinet | Asmadeus