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

[Scott Wood]

On Wed, Jul 21, 2004 at 10:22:18AM +0200, Ingo Molnar wrote:
> we already 'daemonize' softirqs in the stock kernel if the load is high
> enough. (this is what ksoftirqd does) So the only question is a tunable
> to make this deferring of softirq load mandatory. Yarroll's patch is
> quite complex, i dont think that is necessary.

What aspects of it do you find unnecessary?  The second thread is
needed to maintain the current high/low priority semantics (without
that, you'll either starve regular tasks with a lot of softirqs, or
starve softirqs with a busy userspace, depending on how you set the
priority of the softirq thread).

> It also has at least one
> conceptual problem, the NOP-ing of local_bh_disable/enable in case of
> CONFIG_SOFTIRQ_THREADS is clearly wrong. Yarroll?

Why is it "clearly wrong"?  As far as I can tell, the only legitimate
use of it currently is to protect against deadlock (as in
spin_lock_bh()), which is not an issue if all softirqs run from a
thread.  Ksoftirqd already ignores such disabling (unless I'm missing
something?), so code that uses it to synchronize with a softirq is
already broken.

There's also the possibility of code relying on it also being
preempt_disable(); if that's happening, it could be left alone
(though IMHO it'd be better if such code made its dependence on such
behavior explicit), with preempt_disable() being the only real
effect.

> I've added a very simple solution to daemonize softirqs similar to
> Yarroll's patch to the -H5 version of voluntary-preempt:

BTW, it was my patch; Yarroll only submitted it to the list (as he
stated at the time).

-Scott