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

[Yao Yuan]

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

Hi Marc,

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

Do you mean the VM case that VM's vcounter can be changed by hypervisor
in EL2, Thus it's not that absolute in such scenario ?

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