[PATCH v2 03/14] perf cs-etm: Turn on context packet timestamps in per-thread mode

[James Clark]

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
>>