Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock

[Thomas Gleixner <tglx@kernel.org>]

On Sun, May 24 2026 at 14:13, David Woodhouse wrote:
> On Sun, 2026-05-24 at 14:36 +0200, Thomas Gleixner wrote:
>> > But on the other hand, can't the conversion be a whole lot simpler than
>> > get_device_system_crosststamp() because it's not actually dealing with
>> > any timekeepers; it's basically only invoking convert_base_to_cs()?
>> 
>> But what for? If you have PTM, use PRECISE. There is _zero_ value of
>> having pre/post timestamps when the hardware already does the correlated
>> precise sampling, no?
>
> The PTM mode and support of PRECISE (or the variant) is currently
> fairly esoteric: very few devices support it. So I'm not sure we should
> expect generic userspace to always even try.

There are not so many PTM capable devices to begin with. And yes, user
space which cares about time and accuracy _should_ try it.

> So there may be some merit in having EXTENDED use the precise hardware
> paired timestamp. Maybe we don't necessarily care about returning
> *cycles* but if we *do* use a PTM-capable device (and I'm including the
> virt TSC-based ones here too), then we kind of want the ABA *all* to be
> at the same clock cycle. Which is what I've already done for vmclock.

If you can do ABA at the same clock cycle, then just implement the cross
timestamp callback and use that.

For PTM capable devices which lack cross timestamp support in the
driver, adding the magic PTM value field in the ABA timestamp won't make
it magically be filled in. So someone has to touch the driver anyway and
then adding the actual cross time support is not much more effort than
adding support for the new field in the extended callback.

Also user space which wants to use the cycles stuff needs to implement
the new IOCTLs anyway. The cycles won't show up magically in the
existing IOCTLs either. So if you make the data struct identical, then
it's really not rocket science to try precise first and then fallback to
extended.

Actuall with the identical data struct you could make that _ONE_ new
IOCTL and the kernel uses cross time stamps if the device supports it or
extended if not. All it has to do is to report the choice and therefore
the number and nature of the samples back to user space. Not rocket
science either.

But in both variant (separate or unified IOCTL) user space has to handle
the data sets correctly.

No strong opinion on that as I have no clue about user space :)

Thanks,

        tglx