Messages in this thread | | | Date | Wed, 21 Jul 2004 18:37:49 -0400 | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch | From | Scott Wood <> |
| |
On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote: > * Scott Wood <scott@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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |