On Tue, Feb 3, 2026 at 10:17 AM Donglin Peng <[email protected]> wrote: > > On Tue, Feb 3, 2026 at 12:12 AM Steven Rostedt <[email protected]> wrote: > > > > On Mon, 2 Feb 2026 19:15:48 +0800 > > Donglin Peng <[email protected]> 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.
Testing revealed that sorting within resolve_btfids introduces issues with btf__dedup. Therefore, I plan to move the sorting logic directly into btf__add_enum_value and btf__add_enum64_value in libbpf, which are invoked by pahole. However, it means that we need a newer pahole version. > > > > > -- Steve
