On 15/06/2023 12:52, Dominique Martinet wrote: > Jiri Olsa wrote on Thu, Jun 15, 2023 at 10:39:18AM +0200: >>> coming from alpine: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12563 >> >> it's probably burried somewhere in that discussion, but do you have >> kernel version (or commit) where that increase happened? > > Unfortunately not -- we've just tried on the 6.1.33 that's the current > alpine lts kernel, but I cannot say since when this started because > we've just enabled BTF recently. > > Alpine also doesn't seem to keep old versions of apk files on its > mirrors so while it probably has been happening since it got enabled I > don't know how to check, and the commit enabling BTF has been done > without a MR so there's no test log that'd allow seeing the package size > either :/ > >> also link for used config would be great > > alpine has two configs which both exhibit the issue (raw file link on > commit before removing BTF): > https://gitlab.alpinelinux.org/alpine/aports/-/raw/749ee7117e1437b7ab3ef2590f7f2e3558fda3ef/main/linux-lts/virt.ppc64le.config > Size difference for linux-virt: 219 MiB -> 47 MiB > https://gitlab.alpinelinux.org/alpine/aports/-/raw/749ee7117e1437b7ab3ef2590f7f2e3558fda3ef/main/linux-lts/lts.ppc64le.config > Size difference for linux-lts: 306 MiB -> 74 MiB > I took a look (gunzip'ed and tar-extracted the apk to get the vmlinuz-lts file) and the BTF looks reasonable size-wise: $ objdump -h vmlinuz-lts ... 13 .BTF 003d64cc c000000001400844 0000000001400844 01410844 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .BTF_ids 00000248 c0000000017d6d10 00000000017d6d10 017e6d10 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA So BTF is ~4MB if I'm reading the above right. However the problem I suspect is this: 51 .debug_info 0a488b55 0000000000000000 0000000000000000 026f8d20 2**0 CONTENTS, READONLY, DEBUGGING 52 .debug_abbrev 004d66f0 0000000000000000 0000000000000000 0cb81875 2**0 CONTENTS, READONLY, DEBUGGING 53 .debug_line 019192f6 0000000000000000 0000000000000000 0d057f65 2**0 CONTENTS, READONLY, DEBUGGING 54 .debug_frame 002d4fe0 0000000000000000 0000000000000000 0e971260 2**3 CONTENTS, READONLY, DEBUGGING 55 .debug_str 00390822 0000000000000000 0000000000000000 0ec46240 2**0 CONTENTS, READONLY, DEBUGGING 56 .debug_line_str 00000445 0000000000000000 0000000000000000 0efd6a62 2**0 CONTENTS, READONLY, DEBUGGING 57 .debug_loclists 0176a32c 0000000000000000 0000000000000000 0efd6ea7 2**0 CONTENTS, READONLY, DEBUGGING 58 .debug_rnglists 00382d7a 0000000000000000 0000000000000000 107411d3 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. 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 Alan
