Date: Thu, 5 Jan 2006 22:36:23 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Swiger <cswiger@mac.com> Cc: Luigi Rizzo <rizzo@icir.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly Message-ID: <200601060636.k066aNYn079015@apollo.backplane.com> References: <73774.1136109554@critter.freebsd.dk> <20060101035958.A86264@xorpc.icir.org> <43B7E1EC.5090301@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Luigi Rizzo wrote: :> On Sun, Jan 01, 2006 at 10:59:14AM +0100, Poul-Henning Kamp wrote: :>>http://phk.freebsd.dk/misc/leapsecond.txt :>> :>>Notice how CLOCK_REALTIME recycles the 1136073599 second. :> :> on a related topic, any comments on this one ? :> Is this code that we could use ? :> :> http://www.dragonflybsd.org/docs/nanosleep/ : :I ported the tvtohz change from Dragonfly back to 4.10 and 5-STABLE here: : :http://www.pkix.net/~chuck/timer/ : :...so anyone who wants to experiment can try it out. :-) : :-- :-Chuck It isn't so much tvtohz that's the issue, but the fact that the nanosleep() system call has really coarse hz-based resolution. That's been fixed in DragonFly and I would recommend that it be fixed in FreeBSD too. After all, there isn't much of a point having a system call called 'nanosleep' whos time resolution is coarse-grained and non-deterministic from computer to computer (based on how hz was configured). Since you seem to be depending on fine-resolution timers more and more in recent kernels, you should consider porting our SYSTIMER API to virtualize one-shot and periodic-timers. Look at kern/kern_systimer.c in the DragonFly source. The code is fairly well abstracted, operates on a per-cpu basis, and even though you don't have generic IPI messaging I think you could port it without too much trouble. If you port it and start using it you will quickly find that you can't live without it. e.g. take a look at how we implement network POLLING for an example of its use. The polling rate can be set to anything at any time, regardless of 'hz'. Same goes for interrupt rate limiting, various scheduler timers, and a number of other things. All the things that should be divorced from 'hz' have been. For people worried about edge conditions due to multiple unsynchronized timers going off I will note that its never been an issue for us, and in anycase it's fairly trivial to adjust the systimer code to synchronize periodic time bases which run at integer multiples to timeout at the same time. Most periodic time bases tend to operate in this fashion (the stat clock being the only notable exception) so full efficiency can be retained. But, as I said, I've actually done that and not noticed any significant improvement in performance so I just don't bother right now. -Matt Matthew Dillon <dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601060636.k066aNYn079015>