Re: nanosleep returning early

From: Matthew Dillon (dillon_at_apollo.backplane.com)
Date: 07/24/04

  • Next message: Matthias Andree: "Re: xl(4) autonegotiation trouble - ng_pppoe related?" 
    Date: Fri, 23 Jul 2004 15:48:33 -0700 (PDT)
To: Bruce Evans <bde@zeta.org.au>

    :> 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@backplane.com>
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Matthias Andree: "Re: xl(4) autonegotiation trouble - ng_pppoe related?"

    Relevant Pages

    • Re: [RFC][PATCH] Experimental enhanced NTP error accounting patch
      ... The ntp code provides the time update per tick: ... That's all the clock code needs from the ntp code (the details of its ... To keep timeofday the same after changing the multiplier we also have to ...
      (Linux-Kernel)
    • Re: Time dilation
      ... an Earth clock as it leaves Earth, travels to a point a fixed distance, ... With telemetry each tick could be uniquely identified. ... The Earth observer measures the time for the 2 way trip as ...
      (sci.physics.relativity)
    • Re: Is Lorentz contraction a real process
      ... >> slowly, by a very small amount, than a precisely similar clock ... > its tick rate, due to their different PERSPECTIVES. ...
      (sci.physics.relativity)
    • Re: Uncle assAl: (SR) Lorentz t, x = Intervals
      ... So you have one clock B and one clock C, both moving inertially, where ... > During acceleration from rest, clock A intercepts n waves corresponding ... > already moving in the inertial frame that A accelerates into, ... Draw lines from every tick from the source ...
      (sci.physics)
    • Re: Uncle assAl: (SR) Lorentz t, x = Intervals
      ... So you have one clock B and one clock C, both moving inertially, where ... > During acceleration from rest, clock A intercepts n waves corresponding ... > already moving in the inertial frame that A accelerates into, ... Draw lines from every tick from the source ...
      (sci.physics.relativity)