lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ