[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1bef7744-78ef-f673-a33b-6f8fb00e033b@arm.com>
Date: Thu, 19 Oct 2023 11:31:16 +0100
From: James Clark <james.clark@....com>
To: Leo Yan <leo.yan@...aro.org>
Cc: John Garry <john.g.garry@...cle.com>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>
Subject: Re: [PATCH v1 1/2] perf auxtrace: Add 'T' itrace option for timestamp
trace
On 14/10/2023 08:45, Leo Yan wrote:
> An AUX trace can contain timestamp, but in some situations, the hardware
> trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is
> the same source with CPU's time, thus the decoder can not use the
> timestamp trace for samples.
>
> This patch introduces 'T' itrace option. If users know the platforms
> they are working on have the same time counter with CPUs, users can
> use this new option to tell a decoder for using timestamp trace as
> kernel time.
>
> Signed-off-by: Leo Yan <leo.yan@...aro.org>
> ---
> tools/perf/Documentation/itrace.txt | 1 +
> tools/perf/util/auxtrace.c | 3 +++
> tools/perf/util/auxtrace.h | 3 +++
> 3 files changed, 7 insertions(+)
>
> diff --git a/tools/perf/Documentation/itrace.txt b/tools/perf/Documentation/itrace.txt
> index a97f95825b14..19cc179be9a7 100644
> --- a/tools/perf/Documentation/itrace.txt
> +++ b/tools/perf/Documentation/itrace.txt
> @@ -25,6 +25,7 @@
> q quicker (less detailed) decoding
> A approximate IPC
> Z prefer to ignore timestamps (so-called "timeless" decoding)
> + T use the timestamp trace as kernel time
>
Maybe "Treat hardware timestamps as kernel time (trace and CPU time use
same clock source)" would be clearer.
And another point, although this isn't really related to this patch, but
why do we have the single letter arguments for itrace? It seems like it
massively restricts the available options and makes the command lines
hard to read because they don't have long forms. Why not just have them
as normal arguments?
If it's a backwards compatibility thing, would there be any objection to
adding this new option as a normal one rather than an itrace one?
> The default is all events i.e. the same as --itrace=iybxwpe,
> except for perf script where it is --itrace=ce
> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
> index a0368202a746..f528c4364d23 100644
> --- a/tools/perf/util/auxtrace.c
> +++ b/tools/perf/util/auxtrace.c
> @@ -1638,6 +1638,9 @@ int itrace_do_parse_synth_opts(struct itrace_synth_opts *synth_opts,
> case 'Z':
> synth_opts->timeless_decoding = true;
> break;
> + case 'T':
> + synth_opts->use_timestamp = true;
> + break;
> case ' ':
> case ',':
> break;
> diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
> index 29eb82dff574..55702215a82d 100644
> --- a/tools/perf/util/auxtrace.h
> +++ b/tools/perf/util/auxtrace.h
> @@ -99,6 +99,7 @@ enum itrace_period_type {
> * @remote_access: whether to synthesize remote access events
> * @mem: whether to synthesize memory events
> * @timeless_decoding: prefer "timeless" decoding i.e. ignore timestamps
> + * @use_timestamp: use the timestamp trace as kernel time
> * @vm_time_correlation: perform VM Time Correlation
> * @vm_tm_corr_dry_run: VM Time Correlation dry-run
> * @vm_tm_corr_args: VM Time Correlation implementation-specific arguments
> @@ -146,6 +147,7 @@ struct itrace_synth_opts {
> bool remote_access;
> bool mem;
> bool timeless_decoding;
> + bool use_timestamp;
And then this one could be like "hw_time_is_kernel_time", but I'm
stuggling to think of something shorter. Maybe your one is fine along
with the comment.
Powered by blists - more mailing lists