Messages in this thread | | | Date | Thu, 22 Jul 2004 12:06:57 +0200 | From | Ingo Molnar <> | Subject | [patch] voluntary-preempt-2.6.8-rc2-H9 |
| |
* Scott Wood <scott@timesys.com> 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. > > If every such loop in every softirq is taken care of, that would work > (though only until someone adds a new softirq that forgets to check > for preemption). I don't see any such checks in either the transmit > or receive network softirqs in vanilla 2.6.7, though (are they in a > patch, or am I overlooking them?), much less in each individual > driver. There are checks for excessive work (where "excessive" is not > well defined in terms of actual time), but none for need_resched() > except in a few isolated places.
i've added an infrastructure for easy softirq lock-break and preemption to the -H9 version of the voluntary-preempt patch:
http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-H9
in -H9 i've fixed the most important softirq latency sources:
- the RCU code
this one is new and is really bad - it can literally execute tens of thousands of d_callback() functions within rcu_do_batch() causing millisecs of delays - e.g. triggered by the 'du /' test on a box with enough RAM. It affects UP just as much as SMP, in both preempt and non-preempt mode as well.
- the timer code
no real latencies in practice but in theory if enough timers are set to fire in the same jiffy it could be easily unbound.
- net TX/RX code
being the worst offender this had some throttling code already but it didnt listen to resched requests. It does now.
it is really easy to do lock-break of softirqs, one only has to find a place where it's safe to enable softirq processing and do a cond_resched_softirq() call.
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/
| |