On 02/01/20(Thu) 14:29, Scott Cheloha wrote:
> > On Jan 2, 2020, at 9:02 AM, Martin Pieuchot <m...@openbsd.org> wrote:
> >
> > On 01/01/20(Wed) 22:13, Scott Cheloha wrote:
> >>> On Dec 31, 2019, at 9:35 AM, Martin Pieuchot <m...@openbsd.org> wrote:
> >>>
> >>> I'd like to stop converting the given timespec to ticks and instead use
> >>> nanoseconds. This is part of the ongoing effort to reduce the use of
> >>> `hz' through the kernel.
> >>>
> >>> Since I don't know C I'd appreciate any pointer about the checks that
> >>> should be added to TIMESPEC_TO_NSEC().
> >>>
> >>> Then the conversions to {t,rw}sleep_nsec(9) become trivial, diff below.
> >>
> >> We can't do this until timeouts have a tickless interface. Otherwise
> >> your timeouts will return early. That's why I was saving the sys/kern
> >> conversions until after resolving that issue.
> >
> > I don't understand, can you elaborate?
>
> Timeout are scheduled against the current value of "ticks". Any time that
> has elapsed since the current tick began is unaccounted for. You need to
> add a tick to your sleep to account for it. tstohz(9) does this. We don't
> do it automatically for the *sleep_nsec(9) interfaces because that would
> have complicated the conversions we're doing and probably broken callers
> before we were ready to break them.
I question the argument that would complicate the conversions. Isn't it
just a margin of error that is given by the precision of the conversion?
Here it is 1 tick, generally ~10ms. So either the code work with a
sleep of 10ms less or more. Generally it doesn't matter. Now for
userland facing programs you shouldn't wakeup 10ms earlier.
I don't understand why the rounding precision is different between the
two interfaces. We have an interface that adds one tick and one that
doesn't. Both choices are imprecise and should disappear if/when the
guts of the sleep are modified to be tickless (whatever that means).
In the meantime I'd suggest we keep the same behavior between the two
interfaces so we can move forward with the other part of the problem:
the conversion.
It is like doing a refactoring with introducing a behavior change that
prevent us from finishing the refactoring because the change depends on
the internals... Am I going in circle?
PS: What about architectures that won't go tickless? How are we going
to deal with the conversions if there's more than one API?
