Re: FreeBSD handles leapsecond correctly

: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>