Re: a proposed callout API

On Monday 13 November 2006 15:53, Poul-Henning Kamp wrote:
The proposed API
----------------

tick_t XXX_ns_tick(unsigned nsec, unsigned *low, unsigned *high);
Caculate the tick value for a given timeout.
Optionally return theoretical lower and upper limits to
actual value,

tick_t XXX_s_tick(unsigned seconds)
Caculate the tick value for a given timeout.

The point behind these two functions is that we do not want to
incur a scaling operating at every arming of a callout. Very
few callouts use varying timeouts (and for those, no avoidance
is possible), but for the rest, precalculating the correct
(opaque) number is a good optimization.

One note and one question. First, the note. I was planning on rototilling
our sleep() APIs to 1) handle multiple locking primitives, and 2) use
explicit timescales rather than hz. I had intended on using microseconds
with a negative value indicating a relative timeout (so an 'uptime' timeout,
i.e. trigger X us from now) and a positive value indicating an absolute
timeout (time_t-ish, and subject to ntp changes). Partly because (IIRC)
Windows does something similar (negative: relative, positive: absolute, and
in microseconds too IIRC) and Darwin as well. Part of the idea was to fix
places that abused tsleep(..., 1), etc. to figure out a "real" sleep
interval. With your proposal, I would probably change the various sleep
routines to take a tick_t instead. That leads me to my question if if you
would want to support the notion of absolute vs relative timeouts?

Also, my other API change I was going to do was something like this:

msleep() -> mtx_sleep()

msleep_spin() -> sl_sleep() (or some such, was talking with ups@ at BSDCan
about divorcing spin locks from mutexes altogether, including a separate API
namespace, since it's practically already separate as it is)

new functions such as: rw_sleep(), sx_sleep() (ZFS wants this I think), but
this is rather secondary. I'd just rather get the pain and suffering over
all at once.

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

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: a proposed callout API
    ... Caculate the tick value for a given timeout. ... I had intended on using microseconds with a negative value indicating a relative timeout and a positive value indicating an absolute timeout. ...
    (freebsd-arch)
  • 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)
  • Re: Updating callout_reset
    ... Converting from another format to a tick count in callout_resetwould ... Fine tuning the timeout would be a better ... efficiently and avoid representation problems. ... Many callers don't worry much about efficiency and do calculations like ...
    (freebsd-arch)