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

[Scott Wood]

On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
> * Scott Wood <scott at timesys.com> wrote:
> 
> > It appears, though, that recent kernel versions do preempt_disable()
> > in ksoftirqd, apparently to support CPU hotplugging[1].  When I
> > originally made the patch (against 2.6.0), this wasn't the case. 
> > Since it was done so recently, hopefully there are no cases since then
> > that have started depending on this behavior.
> 
> do_softirq() always did a local_bh_disable() which stops preemption, so
> softirq processing was always non-preemptible.

Hmm... I'm not sure how I missed that (probably by misreading the
local_irq_enable() that comes after it as a local_bh_enable()).

> believe me, as someone who took part in the discussions that designed
> softirqs years ago and cleaned up some of it later on, i can tell you
> that this property of softirqs was and is fully intentional. It's not
> just some side-effect that got relied on by random code - it was used
> from day one on. E.g. it enables exclusion against softirq contexts
> without having to use cli/sti.

It'd be nice to use locks that only exclude the specific regions in
the softirqs that are needed, but that's a lot to change at this
point...

> 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.

If every such loop in every softirq is taken care of, that would work
(though only until someone adds a new softirq that forgets to check
for preemption).  I don't see any such checks in either the transmit
or receive network softirqs in vanilla 2.6.7, though (are they in a
patch, or am I overlooking them?), much less in each individual
driver.  There are checks for excessive work (where "excessive" is
not well defined in terms of actual time), but none for need_resched()
except in a few isolated places.

-Scott