On Tue, Oct 14, 2025 at 8:22 AM Alexei Starovoitov <[email protected]> wrote: > > On Mon, Oct 13, 2025 at 5:15 PM Andrii Nakryiko > <[email protected]> wrote: > > > > On Mon, Oct 13, 2025 at 4:53 PM Alexei Starovoitov > > <[email protected]> wrote: > > > > > > On Mon, Oct 13, 2025 at 4:40 PM Andrii Nakryiko > > > <[email protected]> wrote: > > > > > > > > Just a few observations (if we decide to do the sorting of BTF by name > > > > in the kernel): > > > > > > iirc we discussed it in the past and decided to do sorting in pahole > > > and let the kernel verify whether it's sorted or not. > > > Then no extra memory is needed. > > > Or was that idea discarded for some reason? > > > > Don't really remember at this point, tbh. Pre-sorting should work > > (though I'd argue that then we should only sort by name to make this > > sorting universally useful, doing linear search over kinds is fast, > > IMO). Pre-sorting won't work for program BTFs, don't know how > > important that is. This indexing on demand approach would be > > universal. ¯\_(ツ)_/¯ > > > > Overall, paying 300KB for sorted index for vmlinux BTF for cases where > > we repeatedly need this seems ok to me, tbh. > > If pahole sorting works I don't see why consuming even 300k is ok. > kallsyms are sorted during the build too.
Thanks. We did discuss pre-sorting in pahole in the threads: https://lore.kernel.org/all/CAADnVQLMHUNE95eBXdy6=+ghofhrsihmq75gzvgy-hsuhoa...@mail.gmail.com/ https://lore.kernel.org/all/CAEf4BzaXHrjoEWmEcvK62bqKuT3de__+juvGctR3=e8avrw...@mail.gmail.com/ However, since that approach depends on newer pahole features and btf_find_by_name_kind is already being called quite frequently, I suggest we first implement sorting within the kernel, and subsequently add pre-sorting support in pahole. > > In the other thread we discuss adding LOCSEC for ~6M. That thing should > be pahole-sorted too.
