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