Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Thu, Feb 6, 2025 at 5:21 PM Stephen Brennan > <stephen.s.brennan@xxxxxxxxxx> 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/20221104231103.752040-10-stephen.s.brennan@xxxxxxxxxx/ 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. As a separate note for this patch series, we discovered that variables declared twice, where one is declared "__weak", will result in two DWARF variable declarations, and thus two BTF variables. This trips up the BTF validation code. So this series as it is cannot move forward. I'm submitting a fix to dwarves today. Thanks, Stephen
