Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > Gilles Chanteperdrix wrote:
> > > Jan Kiszka wrote:
> > > > Gilles Chanteperdrix wrote:
> > > > > Hi,
> > > > >
> > > > > 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.
> posix 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
Xenomai-core mailing list