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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
