Message-ID:
 <GV1PR08MB1093237396B35459656FF82CA86DEA@GV1PR08MB10932.eurprd08.prod.outlook.com>
Date: Wed, 26 Nov 2025 15:36:58 +0000
From: Al Grant <Al.Grant@....com>
To: James Clark <james.clark@...aro.org>, Leo Yan <Leo.Yan@....com>, Mike
 Leach <mike.leach@...aro.org>
CC: Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jonathan Corbet
	<corbet@....net>, Randy Dunlap <rdunlap@...radead.org>,
	"coresight@...ts.linaro.org" <coresight@...ts.linaro.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>
Subject: RE: [PATCH v7 13/13] coresight: docs: Document etm4x timestamp
 interval option

> On 26/11/2025 2:44 pm, Leo Yan wrote:
> > On Wed, Nov 26, 2025 at 02:20:14PM +0000, Mike Leach wrote:
> >
> > [...]
> >
> >>>>      * - timestamp
> >>>> -     - Session local version of the system wide setting:
> :ref:`ETMv4_MODE_TIMESTAMP
> >>>> -       <coresight-timestamp>`
> >>>> +     - Controls generation and interval of timestamps.
> >>>> +
> >>>> +       0 = off, 1 = minimum interval .. 15 = maximum interval.
> >>>> +
> >>>> +       Values 1 - 14 use a counter that decrements every cycle to generate a
> >>>> +       timestamp on underflow. The reload value for the counter is 2 ^
> (interval
> >>>> +       - 1). If the value is 1 then the reload value is 1, if the value is 11
> >>>> +       then the reload value is 1024 etc.
> >>>> +
> >>>> +       Setting the maximum interval (15) will disable the counter generated
> >>>> +       timestamps, freeing the counter resource, leaving only ones emitted
> when
> >>>> +       a SYNC packet is generated. The sync interval is controlled with
> >>>> +       TRCSYNCPR.PERIOD which is every 4096 bytes of trace by default.
> >>>> +
> >>
> >> What is the default value?
> >
> >  From driver's pespective, the default value is 0 (disabled).  We do
> > set default values in perf:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > e/tools/perf/arch/arm/util/cs-etm.c#n444
> >
> > IIUC, the default value would be the same with or without this series.
> >
> >> 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.)

Al


> I suppose we need to choose what's worse, breaking some subset of Perf
> commands in a slightly annoying way or having two separate options to control
> timestamps that you have to use together. I think it's 50/50, maybe with the
> breakage being the slightly better option.
> 
> 
> >> This is worth mentioning so users can correctly assess what happens
> >> for any existing scripts they might have.
> >>
> >> Based on this then the same command must set the timestamp to 1 -
> >> which will have the same effect as before as we do not want to break
> >> existing behaviour.
> >>
> >> Mike
> >>
> >>
> >>>>      * - cc_threshold
> >>>>        - Cycle count threshold value. If nothing is provided here or the provided
> value is 0, then the
> >>>>          default value i.e 0x100 will be used. If provided value is
> >>>> less than minimum cycles threshold
> >>>>
> >>>> --
> >>>> 2.34.1
> >>>>
> >>
> >>
> >>
> >> --
> >> Mike Leach
> >> Principal Engineer, ARM Ltd.
> >> Manchester Design Centre. UK
> 
> _______________________________________________
> CoreSight mailing list -- coresight@...ts.linaro.org To unsubscribe send an email to
> coresight-leave@...ts.linaro.org

Powered by blists - more mailing lists