On Wed, Nov 26, 2025 at 03:36:58PM +0000, Al Grant wrote:
[...]
As far as I recall when this command line parameter was a bool then: perf -e cs_etm/timestamp/ <program> is sufficient to turn on timestamping.
Hmm... with the latest perf, we must assign value to `timestamp`, otherwise perf will report error:
# /mnt/build/perf record -e cs_etm/timestamp/ -C 0 -- taskset -c 0 ls event syntax error: 'cs_etm/timestamp/' ___ Bad event or PMU
Unable to find PMU or event on a PMU of 'cs_etm'
event syntax error: 'cs_etm/timestamp/' ___ no value assigned for term
event syntax error: 'cs_etm/timestamp/' ___ no value assigned for term Run 'perf list' for a list of valid events
That's unfortunate and not what I expected. And I don't think it makes sense to remove that validation from Perf. The test uses "timestamp=1" so I didn't notice.
Can we accept that people are most likely using the defaults so timestamps are already on and they wouldn't be using it? The only real use case of that at the moment is to do timestamp=0 and that doesn't fail.
Although it's not the default for per-thread mode and I did find the OpenCSD HOWTO.md uses it as an example. timestamps make less sense in per-thread mode as you don't need to correlate between CPUs or watch for context switches.
Timestamps have a more specialised use in per-thread mode, they are as you say less essential for switching in the right context to decode the trace, and less relevant to BOLT/AutoFDO style usage where the trace is collapsed into a heat-map profile.
But trace can also be used to get a detailed timeline of CPU activity - a non-invasive timeline that can trace even through interrupt-disabled kernel code. And for that, having a global constant-frequency timebase becomes more useful, both in its own right, and to line up traces from each CPU with other CPUs and system-level traces. It's also the only way we have to indirectly observe CPU frequency adjustments. (Intel's Processor Trace, which is generally similar to ETM/ETE, has specific packets that trace CPU frequency changes.)
Just clarify a bit to make sure us on the same page.
This series does not break timestamp functionality, it just changes the PMU format 'timestamp' from 1-bit to 4-bits for counter support. The updated 'timestamp' format still supports per-thread mode and CPU wise trace modes.
The only difference is now users need to specify 'cs_etm/timestamp=1/' rather than 'cs_etm/timestamp/' when enabling timestamp. Given PMU format is not an ABI, it is fine for me for the updated format.
To avoid confusion for users, a well-written document is deserved — which is exactly this patch for. And perf log would be helpful. I think we are well prepared for the change.
Thanks, Leo