a proposed callout API
Peter Jeremy
peterjeremy at optushome.com.au
Wed Nov 15 08:40:30 UTC 2006
On Mon, 2006-Nov-13 21:38:21 +0000, Poul-Henning Kamp wrote:
>The other thing is that covering the entire range from hour long
>callouts to nanosecond callouts would require a 64 bit value or
>a tricky pseudo-FP encoding. By splitting them in two classes,
>I can use two different 31 bit encodings separated by the top bit.
This sounds like a pseudo-FP encoding with a very small exponent and a
relatively large mantissa :-)
On Tue, 2006-Nov-14 08:40:37 +0000, Poul-Henning Kamp wrote:
>In message <20061113234305.A34147 at xorpc.icir.org>, Luigi Rizzo writes:
>
>>To make a proper evaluation i would need some idea of the number
>>and distribution of scheduled events on a busy box [...]
>
>So do I.
>
>What is important right now however, is the API. The implementation
>behind it we can change every week if we want, but the API affects
>far too many kernel files to get it wrong.
I don't see anything obviously wrong with the API as proposed. The
use of an opaque tick_t rather than requiring scaling on each call
seems an obvious improvement. That said, is it worthwhile to
instrument the existing callout code to get some statistics on what
actions are frequently used - that might suggest operations that
need to be cheap. (Though identifying high-level actions like
repeat/arm/disarm might be difficult).
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20061115/94e51a9b/attachment.pgp
More information about the freebsd-arch
mailing list