Date: Sat, 18 Feb 2012 22:40:33 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org>, freebsd-hackers@FreeBSD.org Subject: Re: callouts precision Message-ID: <4F400CC1.8030504@FreeBSD.org> In-Reply-To: <4F3FFF33.2050700@FreeBSD.org> References: <4F3FF690.5050600@FreeBSD.org> <4F3FFF33.2050700@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F400CC1.8030504>