Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Feb 2012 21:42:43 +0200
From:      Alexander Motin <mav@FreeBSD.org>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        freebsd-hackers@FreeBSD.org
Subject:   Re: callouts precision
Message-ID:  <4F3FFF33.2050700@FreeBSD.org>
In-Reply-To: <4F3FF690.5050600@FreeBSD.org>
References:  <4F3FF690.5050600@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 18.02.2012 21:05, Andriy Gapon wrote:
> Just want to double-check myself.
> It seems that currently, thanks to event timers, we mostly should be able to
> schedule a hardware timer to fire at almost arbitrary moment with very fine
> precision.
> OTOH, our callout subsystem still seems to be completely tick oriented in the
> sense that all timeouts are specified and kept in ticks.
> As a result, it's impossible to use e.g. nanosleep(2) with a precision better
> than HZ.
>
> How deeply ticks are ingrained into callout(9)?  Are they used only as a measure
> of time?  Or are there any dependencies on them being integers, like for
> indexing, etc?
> In other words, how hard it would be to replace ticks with e.g. bintime as an
> internal representation of time in callout(9) [leaving interfaces alone for the
> start]?  Is it easier to retrofit that code or to replace it with something new?

Pending callouts are now stored in large array of unsorted lists, where 
last bits of callout time is the array index. It is quite effective for 
insert/delete operation. It is ineffective for getting next event time 
needed for new event timers, but it is rare operation. Using arbitrary 
time values in that case is very problematic. It would require complete 
internal redesign.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3FFF33.2050700>