avg at FreeBSD.org
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
>> 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.
More information about the freebsd-hackers