22 Jul
2004
22 Jul
'04
8:20 a.m.
* Scott Wood <scott(a)timesys.com> wrote:
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
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.