Re: [PATCH 2/2] btf: Add the option to include global variable types

Alexei Starovoitov <[email protected]> Thu, 13 Feb 2025 17:18:02 -0800
Newsgroups org.kernel.vger.linux-debuggers,org.kernel.vger.bpf,org.kernel.vger.linux-arch,org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel
Message-ID <CAADnVQKLykG3akdPRTDgHDey9FW1LpixZHjLcj+eG2rhXo7V1w@mail.gmail.com>
On Tue, Feb 11, 2025 at 3:59 PM Stephen Brennan
<[email protected]> wrote:
>
> Alexei Starovoitov <[email protected]> writes:
> > On Thu, Feb 6, 2025 at 5:21 PM Stephen Brennan
> > <[email protected]> wrote:
> >> When the feature was implemented in pahole, my measurements indicated
> >> that vmlinux BTF size increased by about 25.8%, and module BTF size
> >> increased by 53.2%. Due to these increases, the feature is implemented
> >> behind a new config option, allowing users sensitive to increased memory
> >> usage to disable it.
> >>
> >
> > ...
> >> +config DEBUG_INFO_BTF_GLOBAL_VARS
> >> +       bool "Generate BTF type information for all global variables"
> >> +       default y
> >> +       depends on DEBUG_INFO_BTF && PAHOLE_VERSION >= 128
> >> +       help
> >> +         Include type information for all global variables in the BTF. This
> >> +         increases the size of the BTF information, which increases memory
> >> +         usage at runtime. With global variable types available, runtime
> >> +         debugging and tracers may be able to provide more detail.
> >
> > This is not a solution.
> > Even if it's changed to 'default n' distros will enable it
> > like they enable everything and will suffer a regression.
> >
> > We need to add a new module like vmlinux_btf.ko that will contain
> > this additional BTF data. For global vars and everything else we might need.
>
> Fair enough. I believe I had shared Alan Maguire's proof-of-concept for
> that idea a while back for an older version of this feature:
>
> https://lore.kernel.org/all/[email protected]/

Right vmlinux_extra was discussed in various context, so let's make it happen.

> We can dust that off and include it for a new version of this series.
> I'd be curious of what you'd like to see for kernel modules? A
> three-level tree would be too complex, in my opinion.

What is the use case for vars in kernel modules?

> module BTF size increased by 53.2%.

This is the sum of all mods with vars divided by
the sum of all mods without?
Any outliers there?
I would expect modules to have few global variables.

So before we decide on what to do with vars in mods lets figure out
the need.