> Date: Wed, 13 May 2020 16:55:24 +0100
> From: Stuart Henderson <s...@spacehopper.org>
>
> Thanks for looking at this Paul!
>
> On 2020/05/13 17:15, Robert Nagy wrote:
> > On 13/05/20 17:05 +0200, Mark Kettenis wrote:
> > > > The update currently does the work of clock_gettime(), but it can
> > > > probably be changed to only update the timehands and move the logic
> > > > elsewhere. Note that if we expose only the timehands to userland, most
> > > > of the bintime functionality has to also be made available there. Or so
> > > > I think.
> > >
> > > Unfortunately what you're doing here isn't good enough. You're only
> > > exporting low-resolution versions of the clocks. The equivalent of
> > > what Linux class CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE.
> > > And I'm fairly certain that isn't what the applications want. Why
> > > else would they be calling clock_gettime() a gazillion times per
> > > second...
> >
> >
> > Most of the big programs use CLOCK_MONOTONIC.
> >
>
> Agreed.
>
> Quick counts from a dumb search with codesearch.debian:
>
> CLOCK_REALTIME_COARSE 376
> CLOCK_MONOTONIC_COARSE 639
> CLOCK_REALTIME 8756
> CLOCK_MONOTONIC 10776
>
> I have looked over ports source and almost everything I see prefers
> CLOCK_MONOTONIC if available then falls back to CLOCK_REALTIME.
> Occasionally you have things using only CLOCK_REALTIME but not many.
> So I think it's fair to say most of the latter two are overlapping
> cases.
>
> In linux the vdso handles CLOCK_{REALTIME,MONOTONIC}{,_COARSE}.
> Depending on the clock source it may still use syscalls though, people
> got bitten by this on ec2 where some machine types default to a source
> that still needed syscalls.
Given the shitshow that the TSC is on amd64, it is unavoidable that we
end up in that same situation. In theory we could support alternative
hardware clocks as well by memory mapping the HPET read-only into
userland, but that may have unintended side-effects.
