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.
