Hello, On Thu, Mar 06, 2025 at 08:25:01AM +0200, Adrian Hunter wrote: > On 6/03/25 01:28, Namhyung Kim wrote: > > The length of PERF_RECORD_KSYMBOL for BPF is a size of JITed code so > > it'd be 0 when it's not JITed. The ksymbol is needed to symbolize the > > code when it gets samples in the region but non-JITed code cannot get > > samples. Thus it'd be ok to ignore them. > > > > Actually it caused a performance issue in the perf tools on old ARM > > kernels where it can refuse to JIT some BPF codes. It ended up > > splitting the existing kernel map (kallsyms). And later lookup for a > > kernel symbol would create a new kernel map from kallsyms and then > > split it again and again. :( > > > > Probably there's a bug in the kernel map/symbol handling in perf tools. > > But I think we need to fix this anyway. > > > > Reported-by: Kevin Nomura <nomurak@xxxxxxxxxx> > > Cc: Song Liu <song@xxxxxxxxxx> > > Signed-off-by: Namhyung Kim <namhyung@xxxxxxxxxx> > > --- > > tools/perf/util/machine.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > > index 3f1faf94198dbe56..c7d27384f0736408 100644 > > --- a/tools/perf/util/machine.c > > +++ b/tools/perf/util/machine.c > > @@ -779,6 +779,10 @@ int machine__process_ksymbol(struct machine *machine __maybe_unused, > > if (dump_trace) > > perf_event__fprintf_ksymbol(event, stdout); > > > > + /* no need to process non-JIT BPF as it cannot get samples */ > > + if (event->ksymbol.len == 0) > > + return 0; > > Are all ksymbol events BPF? Maybe it is OK > for PERF_RECORD_KSYMBOL_TYPE_OOL also. Perhaps adjust the > comment in that case. Probably, but I didn't see OOL with zero length yet. Is it possible? Thanks, Namhyung
