* [PATCH] perf ftrace latency: Do not read trace files when BPF is used
@ 2026-08-26 18:58 Namhyung Kim
2026-08-26 21:36 ` Ian Rogers
0 siblings, 1 reply; 3+ messages in thread
From: Namhyung Kim @ 2026-08-26 18:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ian Rogers, Jiri Olsa, Adrian Hunter, James Clark,
Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users,
Steven Rostedt, Masami Hiramatsu
I've realized that it didn't set up the tracing files when BPF is used
so poll() just returns immediately. It ends up with calling poll()
unnecessarily in a loop.
BPF still needs the loop to wait for the target process exiting or a
signal from users. Let's sleep for 1 msec and check that.
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
---
tools/perf/builtin-ftrace.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
index 4f881a40c311ae52..e61b9de11e1e41c7 100644
--- a/tools/perf/builtin-ftrace.c
+++ b/tools/perf/builtin-ftrace.c
@@ -1146,6 +1146,11 @@ static int __cmd_latency(struct perf_ftrace *ftrace)
line[0] = '\0';
while (!done) {
+ if (ftrace->target.use_bpf) {
+ usleep(1000);
+ continue;
+ }
+
if (poll(&pollfd, 1, -1) < 0)
break;
--
2.55.0.897.gb25b4bd76c-goog
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] perf ftrace latency: Do not read trace files when BPF is used
2026-08-26 18:58 [PATCH] perf ftrace latency: Do not read trace files when BPF is used Namhyung Kim
@ 2026-08-26 21:36 ` Ian Rogers
2026-08-28 16:59 ` Namhyung Kim
0 siblings, 1 reply; 3+ messages in thread
From: Ian Rogers @ 2026-08-26 21:36 UTC (permalink / raw)
To: Namhyung Kim
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Adrian Hunter, James Clark,
Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users,
Steven Rostedt, Masami Hiramatsu
On Wed, Aug 26, 2026 at 11:58 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> I've realized that it didn't set up the tracing files when BPF is used
> so poll() just returns immediately. It ends up with calling poll()
> unnecessarily in a loop.
>
> BPF still needs the loop to wait for the target process exiting or a
> signal from users. Let's sleep for 1 msec and check that.
>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> tools/perf/builtin-ftrace.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> index 4f881a40c311ae52..e61b9de11e1e41c7 100644
> --- a/tools/perf/builtin-ftrace.c
> +++ b/tools/perf/builtin-ftrace.c
> @@ -1146,6 +1146,11 @@ static int __cmd_latency(struct perf_ftrace *ftrace)
>
> line[0] = '\0';
> while (!done) {
> + if (ftrace->target.use_bpf) {
> + usleep(1000);
> + continue;
> + }
> +
To avoid the busy waiting could we:
```
// Globaly:
sem_t sig_sem;
...
// Prior to setting up the signal handler:
sem_init(&sig_sem, 0, 0);
...
// Here:
if (ftrace->target.use_bpf) {
sem_wait(&sig_sem);
} else {
while (!done) {
...
}
// In the signal handler:
if (ftrace->target.use_bpf) {
sem_post(&sig_sem);
}
...
// After removing the signal handler:
sem_destroy(&sig_sem);
```
Thanks,
Ian
> if (poll(&pollfd, 1, -1) < 0)
> break;
>
> --
> 2.55.0.897.gb25b4bd76c-goog
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] perf ftrace latency: Do not read trace files when BPF is used
2026-08-26 21:36 ` Ian Rogers
@ 2026-08-28 16:59 ` Namhyung Kim
0 siblings, 0 replies; 3+ messages in thread
From: Namhyung Kim @ 2026-08-28 16:59 UTC (permalink / raw)
To: Ian Rogers
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Adrian Hunter, James Clark,
Peter Zijlstra, Ingo Molnar, LKML, linux-perf-users,
Steven Rostedt, Masami Hiramatsu
Hi Ian,
On Wed, Aug 26, 2026 at 02:36:27PM -0700, Ian Rogers wrote:
> On Wed, Aug 26, 2026 at 11:58 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > I've realized that it didn't set up the tracing files when BPF is used
> > so poll() just returns immediately. It ends up with calling poll()
> > unnecessarily in a loop.
> >
> > BPF still needs the loop to wait for the target process exiting or a
> > signal from users. Let's sleep for 1 msec and check that.
> >
> > Cc: Steven Rostedt <rostedt@goodmis.org>
> > Cc: Masami Hiramatsu <mhiramat@kernel.org>
> > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > ---
> > tools/perf/builtin-ftrace.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> > index 4f881a40c311ae52..e61b9de11e1e41c7 100644
> > --- a/tools/perf/builtin-ftrace.c
> > +++ b/tools/perf/builtin-ftrace.c
> > @@ -1146,6 +1146,11 @@ static int __cmd_latency(struct perf_ftrace *ftrace)
> >
> > line[0] = '\0';
> > while (!done) {
> > + if (ftrace->target.use_bpf) {
> > + usleep(1000);
> > + continue;
> > + }
> > +
>
> To avoid the busy waiting could we:
> ```
> // Globaly:
> sem_t sig_sem;
> ...
> // Prior to setting up the signal handler:
> sem_init(&sig_sem, 0, 0);
> ...
> // Here:
> if (ftrace->target.use_bpf) {
> sem_wait(&sig_sem);
> } else {
> while (!done) {
> ...
> }
> // In the signal handler:
> if (ftrace->target.use_bpf) {
> sem_post(&sig_sem);
> }
> ...
> // After removing the signal handler:
> sem_destroy(&sig_sem);
> ```
Looks better, will check.
Thanks,
Namhyung
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-08-28 17:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-26 18:58 [PATCH] perf ftrace latency: Do not read trace files when BPF is used Namhyung Kim
2026-08-26 21:36 ` Ian Rogers
2026-08-28 16:59 ` Namhyung Kim
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®