On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote:
* Scott Wood <scott(a)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