From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: jolsa@kernel.org, ak@linux.intel.com, namhyung@kernel.org,
irogers@google.com, james.clark@arm.com, mpe@ellerman.id.au,
linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
maddy@linux.vnet.ibm.com, rnsastry@linux.ibm.com,
kjain@linux.ibm.com, disgoel@linux.ibm.com
Subject: Re: [PATCH] tools/perf: Fix usage of perf probe when libtraceevent is missing
Date: Wed, 1 Feb 2023 21:50:17 -0300 [thread overview]
Message-ID: <Y9sIyTLHssijIFLT@kernel.org> (raw)
In-Reply-To: <20230131134748.54567-1-atrajeev@linux.vnet.ibm.com>
Em Tue, Jan 31, 2023 at 07:17:48PM +0530, Athira Rajeev escreveu:
> While parsing the tracepoint events in parse_events_add_tracepoint()
> function, code checks for HAVE_LIBTRACEEVENT support. This is needed
> since libtraceevent is necessary for tracepoint. But while adding
> probe points, check for LIBTRACEEVENT is not done in case of perf probe.
> Hence, in environment with missing libtraceevent-devel, it is
> observed that adding a probe point shows below message though it
> can't be used via perf record.
Thanks, applied.
- Arnaldo
> Example:
> Adding probe point:
> ./perf probe 'vfs_getname=getname_flags:72 pathname=result->name:string'
> Added new event:
> probe:vfs_getname (on getname_flags:72 with pathname=result->name:string)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe:vfs_getname -aR sleep 1
>
> But trying perf record:
> ./perf record -e probe:vfs_getname -aR sleep 1
> event syntax error: 'probe:vfs_getname'
> \___ unsupported tracepoint
> libtraceevent is necessary for tracepoint support
> Run 'perf list' for a list of valid events
>
> The builtin tool like perf record needs libtraceevent to
> parse tracefs. But still the probe can be used by enabling
> via tracefs. Patch fixes the probe usage message to the user
> based on presence of libtraceevent. With the fix,
>
> # ./perf probe 'pmu:myprobe=schedule'
> Added new event:
> pmu:myprobe (on schedule)
>
> perf is not linked with libtraceevent, to use the new probe you can use tracefs:
>
> cd /sys/kernel/tracing/
> echo 1 > events/pmu/myprobe/enable
> echo 1 > tracing_on
> cat trace_pipe
> Before removing the probe, echo 0 > events/pmu/myprobe/enable
>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> tools/perf/builtin-probe.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
> index ed73d0b89ca2..e72f6cea76f7 100644
> --- a/tools/perf/builtin-probe.c
> +++ b/tools/perf/builtin-probe.c
> @@ -383,9 +383,18 @@ static int perf_add_probe_events(struct perf_probe_event *pevs, int npevs)
>
> /* Note that it is possible to skip all events because of blacklist */
> if (event) {
> +#ifndef HAVE_LIBTRACEEVENT
> + pr_info("\nperf is not linked with libtraceevent, to use the new probe you can use tracefs:\n\n");
> + pr_info("\tcd /sys/kernel/tracing/\n");
> + pr_info("\techo 1 > events/%s/%s/enable\n", group, event);
> + pr_info("\techo 1 > tracing_on\n");
> + pr_info("\tcat trace_pipe\n");
> + pr_info("\tBefore removing the probe, echo 0 > events/%s/%s/enable\n", group, event);
> +#else
> /* Show how to use the event. */
> pr_info("\nYou can now use it in all perf tools, such as:\n\n");
> pr_info("\tperf record -e %s:%s -aR sleep 1\n\n", group, event);
> +#endif
> }
>
> out_cleanup:
> --
> 2.39.0
>
--
- Arnaldo
next prev parent reply other threads:[~2023-02-02 0:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 13:47 [PATCH] tools/perf: Fix usage of perf probe when libtraceevent is missing Athira Rajeev
2023-02-02 0:50 ` Arnaldo Carvalho de Melo [this message]
2023-02-02 4:17 ` Athira Rajeev
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=Y9sIyTLHssijIFLT@kernel.org \
--to=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=disgoel@linux.ibm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=kjain@linux.ibm.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=rnsastry@linux.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).