FreeBSD handles leapsecond correctly
Matthew Dillon
dillon at apollo.backplane.com
Thu Jan 5 22:36:25 PST 2006
: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 at backplane.com>
More information about the freebsd-current
mailing list