Re: a proposed callout API

John Baldwin wrote:
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)

I've mentionned several times that I think making both the spinlock and Mutex code use the same mutex structure is a problem because one cannot do any run-time checking to ensure that the correct call is being used.. one must instead do runtime checking which is slower and may not hit all unusual cases (except in unusual circumstances).


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.

_______________________________________________
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.e. trigger X us from now) and a positive value indicating an absolute ...
    (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)