On Tue, Oct 14, 2025 at 8:22 AM Alexei Starovoitov
[off-list ref] wrote:

On Mon, Oct 13, 2025 at 5:15 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Mon, Oct 13, 2025 at 4:53 PM Alexei Starovoitov
[off-list ref] wrote:

quoted

On Mon, Oct 13, 2025 at 4:40 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

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-hSuHoaT5A@mail.gmail.com/ (local)
https://lore.kernel.org/all/CAEf4BzaXHrjoEWmEcvK62bqKuT3de__+juvGctR3=e8avRWpMQ@mail.gmail.com/ (local)

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.