Re: Updating callout_reset

From: Bruce Evans (bde_at_zeta.org.au)
Date: 01/26/04

  • Next message: M. Warner Losh: "Re: Device Driver Problem, Embedded Development" 
    Date: Mon, 26 Jan 2004 22:05:37 +1100 (EST)
To: Mike Silbersack <silby@silby.com>

    On Sun, 25 Jan 2004, Mike Silbersack wrote:

    > #1 - At high hz rates, the maximum timeout possible is reduced; we have
    > at least one example of this causing problems in the kernel at present
    > (16-bit sbtimeout values getting reduced from 327 to 32 seconds), there
    > could be others we haven't caught. Many of these are likely to result
    > from integer math errors introduced by authors who hadn't considered
    > larger hz values occuring.

    Changing the interface wouldn't fix this, but would introduce new overflow
    possibilities (when the caller passes a timeout that cannot be represented
    as in "int" tick count).

    > #2 - Using ticks reduces the potential accuracy of wakeups with our
    > default hz setting. For example, if one wishes to sleep for 5ms when
    > hz=100, the only choices is to request one tick, or 10ms. However, if 5ms
    > could be specified, the callout subsystem would be able to schedule more
    > precise wakeups in places where the next timer interval was between 5 and
    > 10ms away.

    Converting from another format to a tick count in callout_reset() would
    be a good pessimization. Fine tuning the timeout would be a better
    pessimization. callout_reset() is designed to be very efficient, partly
    by not looking at its timeout arg. The code to decide how near the next
    tick is would have to make at least an expensive binuptime() call.

    > Case #1 also provides a second justification for a change; any piece of
    > code which requests a timeout must be aware of the system hz; moving to a
    > standard time format would create more straightforward code.

    This is a negative justification. Unless you reimplement callouts and
    make them slower, callers must be aware of their limits to use them
    efficiently and avoid representation problems.

    Many callers don't worry much about efficiency and do calculations like
    (hz / 10) to get the timeout. This is still more efficient than the
    64-bit divisions and other complications needed to handle general
    conversions of times to timeouts. (Look at tvtohz(). Note that the
    complications in it have very little to do with struct timeval not
    being a scalar type. They are to handle representation problems.)

    Bruce
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: M. Warner Losh: "Re: Device Driver Problem, Embedded Development"

    Relevant Pages

    • Re: semTake .. millisecond/microsecond waits
      ... The semTake would return on a timeout between a min of 0 and a max of 0.0166666... ... Since you can't know how far away the next clock tick is, the time that you actually get for the timeout can always be just less than 1 tick of what you asked. ... With the default system clock rate of 60 hz, this will timeout after a minimum of 0.100 and a max of 0.116666... ...
      (comp.os.vxworks)
    • Re: sleep() API behaves differently in Linux 2.4 and Linux 2.6
      ... Linux 2.4.20 it takes about 10 msec. ... The default system timer tick on 2.4 kernels was 10ms. ... 10ms is the minimum amount of time you can sleep. ... timeout is actually a lower bound on the maximimum time slept ...
      (comp.os.linux.development.apps)
    • Re: semTake .. millisecond/microsecond waits
      ... The semTake timeout parameter doesn't provide the granuality I need. ... Since you can't know how far away the next clock tick is, ... With the default system clock rate of 60 hz, ...
      (comp.os.vxworks)
    • Delay loop problem, VB6
      ... Private tick As Boolean, state As Long ... Private Sub Form_Click ... Debug.Print "Timeout 0" ...
      (comp.lang.basic.visual.misc)
    • Quantcast