On 10/09/2026 10:37, Eduard Zingerman wrote: > On Tue, 2026-09-01 at 17:57 +0100, Alan Maguire wrote: >> Extend btf__permute() with an optional transfer mode. Type-map entries >> marked with BTF_PERMUTE_ID_TRANSFER are removed from the input BTF and >> copied into a newly-created split BTF returned through >> btf_permute_opts.transfer_btf. >> >> While moving types, remap type IDs for both retained and transferred >> types, preserving split-BTF references to the parent BTF where needed. >> >> String handling has to be done carefully as we do not want to have >> strings that only exist in the split BTF to impose a cost on the base. >> Copy referenced strings locally first, compact the parent string table >> after the moved types are gone, rebase split-string offsets, and compact >> the split string table. This leaves strings exclusively needed by moved >> types in the split BTF while retaining shared strings in the parent. >> This will be important later for function names of inline-only functions; >> these should not take up space in base BTF but should have strings in >> inline BTF only. >> >> This all provides the support needed to place inline-only BTF >> in a separate BTF section, which resolve_btfids will use later. >> >> Signed-off-by: Alan Maguire <[email protected]> >> Assisted-by: Codex (GPT-5) >> --- > > Hi Alan, > > What do you think about an alternative approach to permute and > resolve_btfids changes described below? > > Instead of specifying a permute mapping can just rebuild two BTFs from > scratch: base BTF w/o LOC types and .BTF.inline BTF with LOC types only. > This would give strings dedup / compaction for free and would not > require further changes in libbpf. > > Concretely, commit [1] (branch [2]) uses the following steps: > - Traverse all types reachable from LOC_PARAM, LOC_PROTO, LOCSEC > entries and mark them as having LOC color. > - Traverse all types reachable from the remaining types > and mark them as having MAIN or SHARED colors. > - Create a new base BTF object and copy all MAIN/SHARED types there. > - Create a new .BTF.inline object with base set to the new base BTF > object, and copy all LOC types there. > > This seem to be on par with your current branch with regards to > speed / memory usage: > > │ Version │ Elapsed, mean ± SEM │ Peak RSS, mean │ > ├─────────────────────────┼─────────────────────┼────────────────┤ > │ Original permute │ 338.8 ± 8.1 ms │ 71.20 MiB │ > │ Proposed │ 284.1 ± 10.2 ms │ 70.10 MiB │ > > But seems a tad simpler in terms of implementation (~ -250 lines of code). > > I also changed how LOC-only FUNC objects are identified, by using a > generic type graph traversal utility function (btf_mark_reachable()). > This is a bit less code and opens a possibility to move some more > types to .BTF.inline: > > │ Section │ Before (bytes) │ After │ Change │ > ├─────────────┼────────────────┼────────────────┼──────────┤ > │ .BTF │ 5,207,078 │ 5,047,510 │ −159,568 │ > │ .BTF.inline │ 9,867,471 │ 10,027,039 │ +159,568 │ > > This is the same change, but when allowed to move regular types from > base to .BTF.inline, if those types are not used by base. > > [1] > https://github.com/eddyz87/bpf/commit/abe515962632ad51f8aa50e44354b88f80bbd606 > [2] https://github.com/eddyz87/bpf/tree/resolve-btf-ids-btf-inline > (tests commit is 100% slop, please ignore it). >
Thanks for doing this Eduard, it looks like a really neat solution! The permutation approach - which is really a permute and a segmentation - felt a bit clunky and doesn't feel like it belongs in libbpf really (it's a very specific problem). I'll play around with this a bit more, and with your permission maybe we could include it in the kbuild inline series? (I'm splitting up the work into the libbpf/kernel location support needed for pahole, and a followup to add the location info) Thanks again! Alan
