Date: Tue, 28 Nov 2006 14:54:24 -0800 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <456CBE20.4010902@elischer.org> In-Reply-To: <200611281631.19224.jhb@freebsd.org> References: <7105.1163451221@critter.freebsd.dk> <200611281631.19224.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?456CBE20.4010902>