Scott Cheloha writes:
> On Fri, Sep 04, 2020 at 05:55:40PM -0500, Scott Cheloha wrote:
>> On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote:
>> > Basically, ticks are a poor approximation for the system clock. We
>> > should use the real thing where possible.
>> >
>> > [...]
>> >
>> > Thoughts on this approach? Thoughts on the proposed API?
>>
>> 6 week bump.
>>
This might not be a very useful data point, but I ran this aggressively
for a couple weeks using clock timeouts for process sleeps, like this:
--- kern/kern_fork.c 20 Mar 2020 08:14:07 -0000 1.225
+++ kern/kern_fork.c 26 Jul 2020 09:34:56 -0000
@@ -166,7 +166,7 @@ thread_new(struct proc *parent, vaddr_t
/*
* Initialize the timeouts.
*/
- timeout_set(&p->p_sleep_to, endtsleep, p);
+ timeout_set_kclock(&p->p_sleep_to, endtsleep, p, 0, KCLOCK_UPTIME);
return p;
}
On a VM which has always had a lot of problems with kqueue timers firing
late and causing dovecot to complain "time jumped forward" in syslog,
using the clock timeouts eliminated the complaints and caught a much
larger number of late timeouts in the kern.timeout_stats.
I didn't notice any adverse side effects and I didn't try to measure
performance impact.
> +uint32_t
> +timeout_maskwheel(uint32_t level, const struct timespec *abstime)
> +{
> + uint32_t hi, lo;
> +
> + hi = abstime->tv_sec << 7;
> + lo = abstime->tv_nsec / 7812500;
> +
> + return ((hi | lo) >> (level * WHEELBITS)) & WHEELMASK;
> +}
I found it a little hard to understand at first where 7812500 came from;
would it be too ugly to write it as (1000000000L / (1 << 7))?
