I was looking at making the network stack a little bit more threaded
on SMP machines. Most of it (at least the packet receive path)
runs in a bottom half. All bottom halves are currently atomic, there
can always run at most one. To spread the packet receive path over
more than one CPU a non-atomic bottom half is needed. The situation
currently is a little bit like the global lock in entry.S in 2.0.x.
All the locking is hidden from the actual subsystems, thus noone
cared about a more intelligent locking strategy that allows for more
parallelism.
There are several possible ways to implement this:
- The bottom half locking is removed at all and all bottom half handlers
should care about locking themselves. That can be made easy at first
by moving the softirq_trylock()/hard_irq_trylock() at first into all bh handlers
(just like the big lock_kernel() overhaul in early 2.1). Then we can look
at adding more parallelism to particular bh handlers.
- A special flag is added to some bottom half handlers that they can run
parallel (needs less code changes at first, but it might be less painful
to do it completely once).
- A new second mechanism for non-atomic bottom halves is added. The parallel
parts of the network stack could be moved into this new handler then. This
could potentially add more latency and races, but has the advantage of not
breaking the old 'atomic' bh paradigm at all.
I think there is also a way needed to allow multithreaded timer handlers.
This could be done by a new argument to addtimer() or some other mechanism.
Comments?
Personally I like the first solution best, and I'm not sure what's the best
way for the timers.
-Andi
P.S.: What's the purpose of previous_irqholder in arch/i386/kernel/irq.c?
As far as I can see it's only assigned to, but never used.