Post by Gilles ChanteperdrixPost by Jan KiszkaPost by Gilles ChanteperdrixPost by Jan KiszkaPost by Gilles ChanteperdrixHi,
here comes, for review, a patch which reduces the overhead of
clock_gettime by directly reading the tsc in user-space for
architectures that support it.
Highly welcome. But I have one concern: How and when do you propagate
wallclock_offset changes to user space?
Since clock_settime is not implemented, never, but if clock_settime was
implemented, clock_settime would re-issue the __xn_sys_info syscall.
This excludes automatic clock adjustment, something I'm convinced we
will have to provide in the future.
When we provide automatic clock adjustment, we will have to devise
something more subtle than just an offset, so we will have to redesign
I think offset + scaling factor.
Post by Gilles Chanteperdrixposix clocks support anyway. Maybe clock_gettime(CLOCK_REALTIME) will
then always be a syscall. After all, rt_timer_read is a syscall. If you
want the fast clock, use CLOCK_MONOTONIC or rt_timer_tsc.
Actually, the issue of the intermediate approach starts earlier: as soon
as you have clock_settime. Then you need to sync the offset across
applications in different processes.
Having clock_monotonic (and maybe also rt_timer_tsc2ns) as a fast
variant already now is not bad. But beyond that, before introducing a
new interface between kernel and user space, I would like to consider
the effort to get it future-proof immediately. That doesn't mean that we
already have to implement clock adjustment, but we may already prepare
the prerequisites.
Jan