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

[Feng Tang]

On Wed, Sep 02, 2026 at 04:32:25PM +0100, Marc Zyngier wrote:
> 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.

Hi Marc,

Thanks for the great inputs!

I forgot to emphasized that this is only a debug option, mostly for bug
chasing. 
 
> 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.

This option is for chasing nasty bugs (involving SCP/ATF), which could
be panic during boot, so debugfs may not work. But yes, we can achieve
this by printing this out in dmesg.

I agree the post-processing logs works, while this option could be more
convenient, for kernel developers, and firmware developers too :)

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

Good point! It may not work for guest environment. And the main purpose
is to debug baremetal issues, which need to cross-check logs from
SCP, ATF and kernel.
 
> I appreciate this is not what your case, but I'm somewhat reluctant to
> burden the kernel with something that is, by definition, unreliable.

You are right! There are all kinds of hardware timers out there, many
of which have various issues, and 'unreliable' for this usage.

The needed features I can think of for a HW timer to use absolute
counter are:
* always running, won't stop on entering cpuidle or system suspend
* won't change frequency on cpufreq change
* the wrap period is big enough

I thought about using CLOCK_SOURCE_SUSPEND_NONSTOP to do a capability
check, but it's not available in sched_clock.c.

So I mentioned in commit log that users enabling this option should
make sure the HW counter is capable.

btw, fwiw, Sashiko also gave some good comments, like I shouldn't use
cyc_to_ns() for calculating the epoch_ns, which should be solved by
using mul_u64_u64_div_u64()

Thanks,
Feng

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Jazz isn't dead. It just smells funny.