> On Jan 2, 2020, at 9:02 AM, Martin Pieuchot <[email protected]> wrote: > > On 01/01/20(Wed) 22:13, Scott Cheloha wrote: >>> On Dec 31, 2019, at 9:35 AM, Martin Pieuchot <[email protected]> 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. When we have a tickless interface for the timeout(9) layer you will be able to set a timeout to expire at a given absolute uptime with nanosecond precision. Then you won't need to work around ticks. It'll be based on the actual system uptime, not "ticks", which is too coarse an approximation. With the aforementioned interface we'll be able to write a *sleep(9) interface that takes advantage of it. And then we can convert the callers in sys/kern.
