Messages in this thread | | | Date | Wed, 21 Jul 2004 23:18:26 +0200 | From | Ingo Molnar <> | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
* 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.
> If preempt-disabled softirqs (and thus a local_bh_disable() that works > for mutual exclusion on the local CPU) become relied upon by random > pieces of kernel code, [...]
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.
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.
Ingo - 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/
| |