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

Ingo Molnar mingo at elte.hu
Wed Jul 21 21:08:32 UTC 2004

* Scott Wood <scott at timesys.com> wrote:

> > > You're still running do_softirq() with preemption disabled, which is
> > > almost as bad as doing it under a lock.
> > 
> > well softirqs are designed like that. 
> And those who wish to continue using them like that can.  However, in
> my patch they never run with preemption disabled, which can result in
> substantial latency improvement (as long as nothing else is causing
> similar delays).  I see nothing in the design that *requires* them to
> continue running with preemption disabled.

did you get my other mail in which i explained how e.g. the networking
code _relies_ on the softirq semantics?

of course you can improve latencies by making something preemptible that
wasnt preemptible before, but if you do that you should be absolutely
sure that it can be done without breaking that code. And in this case it
cannot be done. The comments in your patch also suggest that you were
unsure about this issue:

 +/* As far as I can tell, local_bh_disable() didn't stop ksoftirqd
 +   from running before.  Since all softirqs now run from one of
 +   the ksoftirqds, this shouldn't be necessary. */
 +static inline void local_bh_disable(void)

local_bh_disable() of course stops ksoftirqd from running on that CPU.

> Do you also add preemption checks in all of the various loops that can
> be run from within a single softirq instance?

no, that's the next step, if those loops turn out to be problematic. 
E.g. network device backlogs default to a value of 100 or so which
shouldnt generate too bad latencies. If it does it's easy to break out
of those loops, they are already breakout-aware.


More information about the Linux-audio-dev mailing list