21 Jul
2004
21 Jul
'04
6:11 p.m.
On Wed, Jul 21, 2004 at 08:46:50PM +0200, Ingo Molnar wrote:
* Scott Wood <scott(a)timesys.com> wrote:
And those who wish to continue using them like that can. However, in
my patch they never run with preemption disabled, which can result in
substantial latency improvement (as long as nothing else is causing
similar delays). I see nothing in the design that *requires* them to
continue running with preemption disabled.
Likewise, interrupts are "designed" to be unpreemptible, but it is
possible to run them in their own threads so as to further reduce
sources of latency (at a throughput cost, of course). This allows
long-held spinlocks that an interrupt handler needs to acquire to be
replaced with mutexes that don't inhibit preemption.
Of course, a better fix is to keep the interrupt handlers and
critical sections short, but threading them can be very effective for
producing low latencies in the short term (we were able to achieve
worst measured case latencies of well under 100us on ordinary PC
hardware under 2.4.x using this approach).
You're still running do_softirq() with
preemption disabled, which is
almost as bad as doing it under a lock.
well softirqs are designed like that. I've added extra preemption code to the latest
patch to avoid
repeat processing.
Do you also add preemption checks in all of the various loops that
can be run from within a single softirq instance?
-Scott