callouts precision

Andriy Gapon avg at
Sat Feb 18 20:41:07 UTC 2012

on 18/02/2012 21:42 Alexander Motin said the following:
> 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.

I see.  Thank you for the insight!

One possible hack that I can think of is to use "pseudo-ticks" in the callout
implementation instead of real ticks.  E.g. such a pseudo-tick could be set
equal to 1 microsecond instead of 1/hz (it could be tunable).  Then, of course,
instead of driving the callouts via hardclock/softclock, they would have to be
driven directly from event timers.  And they would have to use current
microseconds uptime instead of ticks, obviously.  This would also require a
revision of types used to store timeout values.  Current 'int' would not be
adequate anymore, it seems.

It looks like Timer_Wheel_T from ACE has some useful enhancements in this direction.

BTW, it seems that with int ticks and HZ of 1000, ticks would overflow from
INT_MAX to INT_MIN in ~24 days.  I can imagine that some code might get confused
by such an overflow.  But that's a different topic.

Andriy Gapon

More information about the freebsd-hackers mailing list