Re: nanosleep returning early

:> Bruce, have you seen this document: <http://www.dragonflybsd.org/docs/nanosleep/>?
:> I'm not looking for a critique here. The document talks about the sleep
:> overruns in various operatingg systems. There is a patch that was applied
:> to DragonFly which aplies to the FreeBSD code base too.
:
:I just looked.  It doesn't apply to FreeBSD.  Adding 1 to the tick
:count in tvtohz() is necessary in many places in FreeBSD (e.g., for
:itimers).  It happens to be just an optimizatiom in nanosleep1() for
:the reasons you mentioned above (going around again fixes any
:underestimate of the tick count, and overestimating by 1 avoids going
:around again in most cases).
:...
:I believe dragonflybsd has high resolution timeouts which make the
:issues different.  `tick' could be somthing like 10**6 and tick counts
:in microseconds would be so large that off by 1 errors in them would
:be too small to measure.
:
:Bruce
:_______________________________________________

    That document doesn't really apply to us anymore either, but I keep
    it up because it's excellent teaching material (esp. the graphs). 

    Yah, DFly's nanosleep now uses our SYSTIMER subsystem and is no longer
    limited by the granularity of the tick clock.  The SYSTIMER subsystem
    is a general purpose, high resolution, MP-friendly, one-shot and
    periodic timer module.  We use it for nanosleep, interrupt rate 
    limiting, and to distribute the various system clocks (hardclock,
    statclock, schedclock, and profiling primarily).  The callback interface
    kinda looks like FAST-INT in FreeBSDspeak, though the abstraction is
    considerably more refined in DFly.

    The interesting issue we have in regards to nanosleep is where
    to cut it off and how closely to try to match the requested timeout
    against the actual timeout based on the overhead of various mechanisms.
    If the request is too small to be worth the overhead of setting up a
    systimer, we try a yield instead.  It's an interesting issue.

    I'd recommend that you guys port it, because you desparately need to
    rewrite your clock distribution code, but its dependant on IPI messaging
    (as are most DFly subsytems) and so you need the IPI messaging 
    abstraction first.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>