Re: Question about ktime_get_mono_fast_ns() non-monotonic behavior

[John Stultz]

On Thu, Oct 13, 2022 at 7:15 PM John Stultz <jstultz@xxxxxxxxxx> wrote:
>
> On Thu, Oct 13, 2022 at 6:29 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote:
> >
> > On Thu, Oct 13, 2022 at 5:03 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Oct 12, 2022 at 8:07 PM John Stultz <jstultz@xxxxxxxxxx> wrote:
> > > >
> > > > On Wed, Oct 12, 2022 at 8:02 PM John Stultz <jstultz@xxxxxxxxxx> wrote:
> > > > > On Mon, Sep 26, 2022 at 2:18 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote:
> > > > > So I think it reasonable to say its bounded by approximately  2 *
> > > > > NSEC_PER_SEC/HZ +/- 11%.
> > > >
> > > > Sorry, this should be 2*NSEC_PER_SEC/HZ * 0.11
> > >
> > > Thanks so much for the detailed response :)
> > >
> > > IIUC this error bound is in ns. So on a 2 GHz cpu the bound is 0.11 ns
> > > (essentially 0)? I feel like I miscalculated, this error bound is too
> > > good to be true.
> >
> > Never mind, I thought HZ is the cpu speed for some reason. It's the
> > number of jiffies per second, right?
>
> Correct.
>
> > So if HZ is 1000, the error bound is actually ~2 ms, which is very
> > large considering that the unit is ns.
>
> Uh, for HZ=1000, I think it's closer to 220us, but yes, for HZ=100 2.2ms.

And again, it has been awhile since I've been deep in this code, so
I'd not be surprised if I'm missing something and the worst case may
be larger (things like SMIs or virtualization stalling the timekeeping
update for longer than a tick).  So no promises, but this feels pretty
close to the expected bound. If you can't handle time inconsistencies,
you need to use the normal locked accessors.

thanks
-john