On Wed, Jul 21, 2004 at 03:14:23PM -0700, Bill Huey wrote:
On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar
wrote:
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.
These folks are tring to make the entire kernel fully preemptable,
possibly, to handle arbitrary preemption at any point during the
execution. It's a noble task to make the kernel preemptable in that
way, but what I've seen is that the use of non-preemptive critical
sections commits all locks below it in the call/lock graph to also
be non-preemptive critical sections and therefore forcing the use
of traditional lock-break and other techniques to lower latency.
One thing that would preserve the correctness of this system might be to
use a per-CPU blocking lock to directly back the uses of local_bh_*
functions explicitly. This altered system would be functionally isomorphic,
but would permit preemption in bhs.
This is something I've been thinking about for a while so it could be
off track or wrong and I'm open (pleading) for correction.
It's a radical departure from the current "deferred-everthing" model
that Linux and many other general purpose OSes are currently using.
The overall performance penalty is unknown, but the possiblity of
lowering latency could still be very significant.
bill