Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Scott Wood (scott_AT_timesys.com)
Date: Wed Jul 21 2004 - 22:56:50 EEST
On Wed, Jul 21, 2004 at 08:46:50PM +0200, Ingo Molnar wrote:
> * Scott Wood <scott_AT_timesys.com> 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
This archive was generated by hypermail 2b28 : Fri Jul 30 2004 - 10:18:09 EEST