On Wed, Oct 15, 2025 at 9:54 AM Alexei Starovoitov
<[email protected]> wrote:
>
> On Mon, Oct 13, 2025 at 9:53 PM Donglin Peng <[email protected]> wrote:
> >
> > I’d like to suggest a dual-mechanism approach:
> > 1. If BTF is generated by a newer pahole (with pre-sorting support), the
> > kernel would use the pre-sorted data directly.
> > 2. For BTF from older pahole versions, the kernel would handle sorting
> > at load time or later.
>
> The problem with 2 is extra memory consumption for narrow
> use case. The "time cat trace" example shows that search
> is in critical path, but I suspect ftrace can do it differently.
> I don't know why it's doing the search so much.
Thanks. The reason is that ftrace supports outputting parameters of traced
functions through funcgraph-args, like this:
0) | vfs_write(file=0xffff888102b17380,
buf=0x7ffd1e9faaf7, count=0x1, pos=0xffffc90006f83ef0) {
0) | rw_verify_area(read_write=1,
file=0xffff888102b17380, ppos=0xffffc90006f83ef0, count=0x1) {
0) |
security_file_permission(file=0xffff888102b17380, mask=2) {
0) |
selinux_file_permission(file=0xffff888102b17380, mask=2) {
0) 0.111 us | avc_policy_seqno();
0) 0.380 us | }
0) 0.585 us | }
0) 0.782 us | }
which requires obtaining function parameter names and types from BTF.
However, there is currently no direct mapping from function addresses to
btf_type index information. Therefore, it first obtains the function name from
the function address, and then searches the BTF file by the function name
to get the corresponding btf_type.
> Everyelse in bpf we don't call it that often.
> So optimizing the search is nice, but not at the expense
> of so much extra memory.
> Hence I don't think 2 is worth doing.
Thanks, I agree.
>
> > Regarding the pahole changes: this is now my highest priority. I’ve
> > already incorporated it into my development plan and will begin
> > working on the patches shortly.
>
> let's land pahole changes first.
Understood, thanks
