All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org, bpf@vger.kernel.org,
	Kevin Nomura <nomurak@google.com>, Song Liu <song@kernel.org>
Subject: Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
Date: Wed, 5 Mar 2025 23:50:37 -0800	[thread overview]
Message-ID: <Z8lTzROPDcoPQXFZ@google.com> (raw)
In-Reply-To: <bb2b30a1-8ce3-4565-b17a-27148234c10b@intel.com>

On Thu, Mar 06, 2025 at 08:48:20AM +0200, Adrian Hunter wrote:
> 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@google.com>
> >>> Cc: Song Liu <song@kernel.org>
> >>> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> >>> ---
> >>>  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

Then I think it's ok to leave the comment as is.

Thanks,
Namhyung


  reply	other threads:[~2025-03-06  7:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 23:28 [PATCH] perf report: Do not process non-JIT BPF ksymbol events Namhyung Kim
2025-03-06  4:09 ` Song Liu
2025-03-06  6:25 ` Adrian Hunter
2025-03-06  6:45   ` Namhyung Kim
2025-03-06  6:48     ` Adrian Hunter
2025-03-06  7:50       ` Namhyung Kim [this message]
2025-03-07 18:09 ` Namhyung Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z8lTzROPDcoPQXFZ@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nomurak@google.com \
    --cc=peterz@infradead.org \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.