Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Oct 1995 18:50:30 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-hackers@freebsd.org, j@uriah.heep.sax.de
Subject:   Re: What is the best way...
Message-ID:  <199510230850.SAA20756@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>...to implement something similar to the xxx_poll() driver entry
>points in SysV?

>For those whod don't know, these entries are supposed to be called on
>each clock tick (at spl6, i think this is `soft clock'), and they are
>useful for devices that lose interrupts, or that don't even have an
>interrupt of its own.

I prefer periodic timeouts (standard timeouts that get repeated
automatically).

>The closest thing one could do (besides from the approach e.g.
>pcaudio is using, which i consider being overkill as a poll()
>replacement) were to continuously re-issue yet another timeout on each
>clock tick.  However, since that would cause timeout() to walk the
>entire timer queue, it's rather expensive.

timeout() seems to be fairly inexpensive at least when the queue is
short.  I've thought of having separate queues for periodic timeouts
at frequencies hz, hz/10, hz/100, ...  but timeouts can be
dispatched more efficiently from a single delta queue than from
multiple queues.  If timeout() is too slow then I think effort would
be better spent speeding it up, perhaps by using binary search.

It's surprising how many improvement possibilities there are for
something as basic as timeouts.  Other possibilities:

1) high resolution timeouts (vary the clock's maximum count so that
clock interrupts occur when you want them, not periodically).  Heavy
use of periodic timeouts would defeat optimization possibilities
here (reprogramming the clock isn't free but you could hope to gain
by taking less interrupts.  Periodic interrupts would have to be
simulated and ones at frequency `hz' would cost more than now).

2) timeouts that act at higher ipls.  Currently, timeouts can only
occur at splsoftclock().  "Unimportant" hardware activity such as
IDE disk transfers can delay timeouts by several clock ticks.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510230850.SAA20756>