From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 20:41:07 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61101106566C; Sat, 18 Feb 2012 20:41:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 748728FC0C; Sat, 18 Feb 2012 20:41:06 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA20902; Sat, 18 Feb 2012 22:41:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ryr5c-000Cbk-G3; Sat, 18 Feb 2012 22:41:04 +0200 Message-ID: <4F400CC1.8030504@FreeBSD.org> Date: Sat, 18 Feb 2012 22:40:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120215 Thunderbird/10.0.1 MIME-Version: 1.0 To: Alexander Motin , freebsd-hackers@FreeBSD.org References: <4F3FF690.5050600@FreeBSD.org> <4F3FFF33.2050700@FreeBSD.org> In-Reply-To: <4F3FFF33.2050700@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Re: callouts precision X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 20:41:07 -0000 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