Re: [PATCH] sched_clock: Add option to use absolute time against hardware clock reset

[Marc Zyngier]

On Wed, 02 Sep 2026 09:21:23 +0100,
Feng Tang <feng.tang@xxxxxxxxxxxxxxxxx> wrote:
> 
> Currently sched_clock shows the relative time to the boot starting of
> kernel, while there could be long firmware start time before it and
> after the hardware reset.
> 
> On modern server platforms, there could be several software running in
> parallel. Like for arm64, it could have  SCP (System Control Processor)
> firmware running on SCP processor, and ATF (Arm Trusted Firmware) and
> Linux OS on the main processor.
> 
> Debugging some nasty issues on these platform may need to cross-check
> the logs from these firmwares and Linux kernel for specific events,
> where a unified reference timeline is critical. All these software can
> read the hardware timer, which is also the base of sched_clock for
> Linux kernel. Using the absolute counter since hardware timer reset
> makes it possible for all kinds of software to have a same time base.
> 
> Add 'abs_sched_clock' parameter to provide an option for using absolute
> counter, and users should make sure their sched_clock (hardware timer)
> is capable of supporting absolute counter before enabling the option.
> 
> Locally, it did help on chasing some RAS issues which needed cooperation
> between kernel, SCP firmware and ATF, by mapping the actions from each
> players into one timeline based on the timestamps in their logs.

I really have to ask: why isn't this just a one-off sampling of the
counter, kept in some user accessible location (debugfs or something
else), and ultimately post-processed to align your logs? People have
been doing this... forever, and that has been "good enough" so far.

The other thing is that your "absolute" clock isn't absolute at
all. This doesn't consider SW running at EL2 that could happily offset
thing by an arbitrary value.

I appreciate this is not what your case, but I'm somewhat reluctant to
burden the kernel with something that is, by definition, unreliable.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.