a proposed callout API

John Baldwin jhb at freebsd.org
Tue Nov 28 13:40:25 PST 2006


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


More information about the freebsd-arch mailing list