On Wed, Jul 21, 2004 at 08:46:50PM +0200, Ingo Molnar wrote: > * Scott Wood <[EMAIL PROTECTED]> wrote: > > > 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.
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). > 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
