public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] perf report: Do not process non-JIT BPF ksymbol events
@ 2025-03-05 23:28 Namhyung Kim
  2025-03-06  4:09 ` Song Liu
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Namhyung Kim @ 2025-03-05 23:28 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang
  Cc: Jiri Olsa, Adrian Hunter, Peter Zijlstra, Ingo Molnar, LKML,
	linux-perf-users, bpf, Kevin Nomura, Song Liu

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;
+
 	if (event->ksymbol.flags & PERF_RECORD_KSYMBOL_FLAGS_UNREGISTER)
 		return machine__process_ksymbol_unregister(machine, event,
 							   sample);
-- 
2.48.1.711.g2feabab25a-goog


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
  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-07 18:09 ` Namhyung Kim
  2 siblings, 0 replies; 7+ messages in thread
From: Song Liu @ 2025-03-06  4:09 UTC (permalink / raw)
  To: Namhyung Kim
  Cc: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang, Jiri Olsa,
	Adrian Hunter, Peter Zijlstra, Ingo Molnar, LKML,
	linux-perf-users, bpf, Kevin Nomura

On Wed, Mar 5, 2025 at 3:28 PM Namhyung Kim <namhyung@kernel.org> 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>

Acked-by: Song Liu <song@kernel.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
  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-07 18:09 ` Namhyung Kim
  2 siblings, 1 reply; 7+ messages in thread
From: Adrian Hunter @ 2025-03-06  6:25 UTC (permalink / raw)
  To: Namhyung Kim, Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang
  Cc: Jiri Olsa, Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users,
	bpf, Kevin Nomura, Song Liu

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.

> +
>  	if (event->ksymbol.flags & PERF_RECORD_KSYMBOL_FLAGS_UNREGISTER)
>  		return machine__process_ksymbol_unregister(machine, event,
>  							   sample);


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
  2025-03-06  6:25 ` Adrian Hunter
@ 2025-03-06  6:45   ` Namhyung Kim
  2025-03-06  6:48     ` Adrian Hunter
  0 siblings, 1 reply; 7+ messages in thread
From: Namhyung Kim @ 2025-03-06  6:45 UTC (permalink / raw)
  To: Adrian Hunter
  Cc: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang, Jiri Olsa,
	Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users, bpf,
	Kevin Nomura, Song Liu

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?

Thanks,
Namhyung


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
  2025-03-06  6:45   ` Namhyung Kim
@ 2025-03-06  6:48     ` Adrian Hunter
  2025-03-06  7:50       ` Namhyung Kim
  0 siblings, 1 reply; 7+ messages in thread
From: Adrian Hunter @ 2025-03-06  6:48 UTC (permalink / raw)
  To: Namhyung Kim
  Cc: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang, Jiri Olsa,
	Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users, bpf,
	Kevin Nomura, Song Liu

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
  2025-03-06  6:48     ` Adrian Hunter
@ 2025-03-06  7:50       ` Namhyung Kim
  0 siblings, 0 replies; 7+ messages in thread
From: Namhyung Kim @ 2025-03-06  7:50 UTC (permalink / raw)
  To: Adrian Hunter
  Cc: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang, Jiri Olsa,
	Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users, bpf,
	Kevin Nomura, Song Liu

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] perf report: Do not process non-JIT BPF ksymbol events
  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-07 18:09 ` Namhyung Kim
  2 siblings, 0 replies; 7+ messages in thread
From: Namhyung Kim @ 2025-03-07 18:09 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, Ian Rogers, Kan Liang, Namhyung Kim
  Cc: Jiri Olsa, Adrian Hunter, Peter Zijlstra, Ingo Molnar, LKML,
	linux-perf-users, bpf, Kevin Nomura, Song Liu

On Wed, 05 Mar 2025 15:28:38 -0800, 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. :(
> 
> [...]
Applied to perf-tools-next, thanks!

Best regards,
Namhyung



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2025-03-07 18:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2025-03-07 18:09 ` Namhyung Kim

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox