Re: [PATCH v2 03/14] perf cs-etm: Turn on context packet timestamps in per-thread mode
From: James Clark
Date: Thu Oct 08 2026 - 06:18:02 EST
On 26/08/2026 16:36, Leo Yan wrote:
On Fri, Aug 21, 2026 at 10:49:01AM +0100, James Clark wrote:
@@ -453,13 +453,22 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
*/
evsel__set_sample_bit(cs_etm_evsel, CPU);
- /*
- * Also the case of per-cpu mmaps, need the contextID in order to be notified
- * when a context switch happened.
- */
if (!perf_cpu_map__is_any_cpu_or_is_empty(cpus)) {
+ /*
+ * Timestamps are required to interleave samples from different
+ * CPUs.
+ */
evsel__set_config_if_unset(cs_etm_evsel, "timestamp", 1);
+ /* Context IDs are required to associate trace to a process */
evsel__set_config_if_unset(cs_etm_evsel, "contextid", 1);
+ } else {
+ /*
+ * Enable context packet timestamps only (no periodic
+ * timestamps). Even in per-thread mode with a single process we
+ * still need to correlate trace to a specific mmap around
+ * execs, which can be done with just context packet timestamps.
Could we use terminology that is aligned with the ETM spec?
"Disable periodic timestamps but generate timestamps for trace
synchronization ... to a specific mmap around execs, which
can be done with just timestamps of trace synchronization."
Done.
+ */
+ evsel__set_config_if_unset(cs_etm_evsel, "timestamp", UINT64_MAX);
It seems this will eventually convert UINT64_MAX to 0xf for the
timestamp bit field. Why not use 0xf directly to avoid confusion?
Then it wouldn't support the size of the field changing. I thought that was the point of the kernel publishing the fields dynamically. Hard coding widths and positions in userspace only caused issues in the past.
I don't think "...MAX" is confusing for what the intention is, but maybe a comment would be better than hard coding it?
}
/*
--
2.43.0