On 6/03/25 08:45, Namhyung Kim wrote: > 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? Probably not
