21 Jul
2004
21 Jul
'04
8:29 p.m.
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.
Adding preemption points helps with the problems, but isn't something
that can be guaranteed to have a certain latency within N numbers of
context switches and some rescheduling computations, etc...
IMO, this is something that the Linux community should think about
being friendly to or have some kind of consideration for the possibility
of this.
bill