[linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Bill Huey (hui)]

On Wed, Jul 21, 2004 at 03:14:23PM -0700, Bill Huey wrote:
> On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
> > trying to make softirqs preemptible surely wont fly for 2.6 and it will
> > also overly complicate the softirq model. What's so terminally wrong
> > about adding preemption checks to the softirq paths? It should solve the
> > preemption problem for good. The unbound softirq paths are well-known
> > (mostly in the networking code) and already have preemption-alike
> > checks.
> 
> These folks are tring to make the entire kernel fully preemptable,
> possibly, to handle arbitrary preemption at any point during the
> execution. It's a noble task to make the kernel preemptable in that
> way, but what I've seen is that the use of non-preemptive critical
> sections commits all locks below it in the call/lock graph to also
> be non-preemptive critical sections and therefore forcing the use
> of traditional lock-break and other techniques to lower latency.

One thing that would preserve the correctness of this system might be to
use a per-CPU blocking lock to directly back the uses of local_bh_*
functions explicitly. This altered system would be functionally isomorphic,
but would permit preemption in bhs.

This is something I've been thinking about for a while so it could be
off track or wrong and I'm open (pleading) for correction.

It's a radical departure from the current "deferred-everthing" model
that Linux and many other general purpose OSes are currently using.
The overall performance penalty is unknown, but the possiblity of
lowering latency could still be very significant.

bill