From: Namhyung Kim <namhyung@kernel.org>
To: Steven Rostedt <rostedt@kernel.org>
Cc: Ian Rogers <irogers@google.com>,
linux-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [for-next][PATCH 10/15] tracing: Allow perf to read synthetic events
Date: Fri, 22 May 2026 09:03:47 -0700 [thread overview]
Message-ID: <ahB-YxS4skLSTu86@google.com> (raw)
In-Reply-To: <20260522114126.5df2f008@gandalf.local.home>
Hello,
On Fri, May 22, 2026 at 11:41:26AM -0400, Steven Rostedt wrote:
> On Fri, 22 May 2026 08:19:36 -0700
> Ian Rogers <irogers@google.com> wrote:
>
> > On Fri, May 22, 2026 at 7:35 AM Steven Rostedt <rostedt@kernel.org> wrote:
> > >
> > > From: Steven Rostedt <rostedt@goodmis.org>
> > >
> > > Currently, perf can not enable synthetic events. When it does, it either
> > > causes a warning in the kernel or errors with "no such device".
> > >
> > > Add the necessary code to allow perf to also attach to synthetic events.
> >
> > Thanks so much for doing this work! I hoped to spend some time testing
> > it, but there's never enough time. For the synthetic event I was
>
> I totally understand not having time. Heck, I'm currently unemployed and
> I'm still having a hard time finding time!
:)
>
> > wondering what values end up in the perf sample like 'period'? I can
>
> You mean to poll on the event?
>
> > imagine this being the case and that, if you are doing something like
> > a futex wait duration, having to interpret the raw data rather than
> > just getting aggregation for free in `perf report` via the period.
> > That's not wrong but I was just curious.
>
> I guess I'm not quite sure what you mean by "the period". But then again, I
> don't use perf that much.
Oh, it's about the value of the event.
IIUC, the period of any tracepoints is the number of times it hits.
Using a field of tracepoint instead needs interpretation of the event.
Thanks,
Namhyung
next prev parent reply other threads:[~2026-05-22 16:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 14:35 [for-next][PATCH 00/15] tracing: Updates for 7.2 Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 01/15] tracing: Remove redundant IS_ERR() check in trace_pipe_open() Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 02/15] seq_buf: Export seq_buf_putmem_hex() and add KUnit tests Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 03/15] tracing: Bound synthetic-field strings with seq_buf Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 04/15] tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled() Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 05/15] tracing: Remove local variable for argument detection from trace_printk() Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 06/15] tracing: Switch trace_recursion_record.c code over to use guard() Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 07/15] tracefs: Fix typo in a comment of eventfs_callback() kerneldoc Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 08/15] cpufreq: amd-pstate: Use trace_call__##name() at guarded tracepoint call site Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 09/15] HID: Use trace_call__##name() at guarded tracepoint call sites Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 10/15] tracing: Allow perf to read synthetic events Steven Rostedt
2026-05-22 15:19 ` Ian Rogers
2026-05-22 15:41 ` Steven Rostedt
2026-05-22 16:03 ` Namhyung Kim [this message]
2026-05-22 14:35 ` [for-next][PATCH 11/15] tracing/branch: Use pr_warn() instead of printk(KERN_WARNING) Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 12/15] tracing: Use krealloc_array() for trace option array growth Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 13/15] tracing: Fix README path for synthetic_events Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 14/15] tracing: Simplify pages allocation for tracing_map logic Steven Rostedt
2026-05-22 14:35 ` [for-next][PATCH 15/15] tracing: Move trace_iterator_increment() into trace_find_next_entry_inc() Steven Rostedt
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=ahB-YxS4skLSTu86@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox