Message-ID: <CAErzpmuFQqT3+7cSjq4HrYj0Bp_qjagJSh313_ePJxs+0QjVFA@mail.gmail.com>
Date: Tue, 3 Feb 2026 10:17:32 +0800
From: Donglin Peng <dolinux.peng@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>, andrii.nakryiko@...il.com
Cc: ast@...nel.org, mhiramat@...nel.org, linux-kernel@...r.kernel.org, 
	Donglin Peng <pengdonglin@...omi.com>, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] tracing: resolve enum names for function arguments
 via BTF

On Tue, Feb 3, 2026 at 12:12 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Mon,  2 Feb 2026 19:15:48 +0800
> Donglin Peng <dolinux.peng@...il.com> wrote:
>
> > @@ -754,6 +755,14 @@ void print_function_args(struct trace_seq *s, unsigned long *args,
> >                       break;
> >               case BTF_KIND_ENUM:
> >                       trace_seq_printf(s, "%ld", arg);
> > +                     for_each_enum(i, t, enump) {
> > +                             if (arg == enump->val) {
> > +                                     trace_seq_printf(s, " [%s]",
> > +                                                      btf_name_by_offset(btf,
> > +                                                      enump->name_off));
> > +                                     break;
> > +                             }
> > +                     }
> >                       break;
>
> I have to ask; how big is that enum list?

Based on local vmlinux analysis (6.18 kernel):
- 78% enums have vlen ≤ 10
- 95% enums have vlen ≤ 50
- Max observed vlen: 349 (extremely rare case)

$ bpftool btf dump file x86_64/vmlinux | grep "^\[" | grep ENUM | grep
-v "(anon)" | awk -F '[ =]' '{
    for(i=1; i<=NF; i++) {
        if ($i == "vlen") {
            count[$(i+1)]++
        }
    }
}
END {
    for (vlen in count) {
        print "vlen=" vlen ": " count[vlen] " times"
    }
}' | sort -k 2 -n
vlen=104: 1 times
vlen=114: 1 times
vlen=116: 1 times
vlen=129: 1 times
vlen=146: 1 times
vlen=167: 1 times
vlen=181: 1 times
vlen=183: 1 times
vlen=201: 1 times
vlen=213: 1 times
vlen=33: 1 times
vlen=349: 1 times
vlen=42: 1 times
vlen=45: 1 times
vlen=48: 1 times
vlen=50: 1 times
vlen=54: 1 times
vlen=55: 1 times
vlen=56: 1 times
vlen=59: 1 times
vlen=60: 1 times
vlen=61: 1 times
vlen=64: 1 times
vlen=68: 1 times
vlen=71: 1 times
vlen=74: 1 times
vlen=83: 1 times
vlen=85: 1 times
vlen=87: 1 times
vlen=122: 2 times
vlen=38: 2 times
vlen=39: 2 times
vlen=43: 2 times
vlen=44: 2 times
vlen=49: 2 times
vlen=52: 2 times
vlen=58: 2 times
vlen=73: 2 times
vlen=79: 2 times
vlen=35: 3 times
vlen=41: 3 times
vlen=46: 3 times
vlen=25: 4 times
vlen=27: 4 times
vlen=28: 4 times
vlen=29: 4 times
vlen=34: 4 times
vlen=37: 4 times
vlen=40: 4 times
vlen=19: 5 times
vlen=30: 5 times
vlen=20: 6 times
vlen=22: 6 times
vlen=24: 6 times
vlen=16: 8 times
vlen=23: 8 times
vlen=26: 8 times
vlen=31: 8 times
vlen=32: 8 times
vlen=17: 11 times
vlen=18: 12 times
vlen=21: 12 times
vlen=15: 13 times
vlen=14: 21 times
vlen=12: 25 times
vlen=13: 25 times
vlen=10: 34 times
vlen=11: 35 times
vlen=1: 58 times
vlen=8: 70 times
vlen=9: 74 times
vlen=7: 102 times
vlen=6: 108 times
vlen=5: 170 times
vlen=2: 193 times
vlen=4: 250 times
vlen=3: 333 times

>
> Do we really want to do a linear search for every enum we come across?

I think linear search is efficient for typical enum value lists (vlen < 10), I
also support using binary search where feasible.

>
> What we could do is for the first time we hit an enum, create an array of
> enums, sort them, and do a binary search from then on. This could be saved
> in the tracing code itself (in kernel/trace/trace_btf.c), if BPF doesn't
> care about it.

I think this approach adds unnecessary complexity. Instead, we could
leverage btf2btf during the resolve_btfids phase to proactively sort the
btf_enum entries of enum-type btf_type by their value, enabling efficient
binary search lookups.

>
> -- Steve

Powered by blists - more mailing lists