Messages in this thread |  | | Date | Sat, 28 Feb 2009 14:46:26 +0100 | | From | Stefan Richter <> | | Subject | Re: [patch 4/4] genirq: add support for threaded interrupt handlers |
| |
Steven Rostedt wrote: > The way softirqs are currently designed, you can not run them from > the irq thread. We discovered this (the hard way) in the preempt-rt > kernel. The issue is that each softirq (threaded in preempt-rt, with a > thread for every CPU. ie. net-rx/0 net-rx/1 net-rx/2 net-rx/3 for a 4 CPU > box) is bound to a specific CPU. The design is to modify per cpu data. If > a IRQ thread were to run the softirq code and migrate to another CPU, you > will have very hard to debug crashes on your hands.
I presume that a lot of tasklet users rely on the fact that tasklets are executed on the CPU which scheduled them. (E.g. the firewire stack's low level currently does.)
> We also tried to bind the IRQ thread to the CPU if it were to run a > softirq. But that too had issues. If the IRQ thread was bound to a CPU and > a higher priority process preempted it, that IRQ handler could not migrate > to another CPU to finish the work. Now the IRQ handler would need to wait > for that high priority process to give up the CPU in order to continue. > > The solution is to redesign the softirq code to handle migration.
Do you mean "redesign the softirq framework" or "redesign the softirq framework users"?
(In the particular case of firewire, the latter should be just fine.) -- Stefan Richter -=====-==--= --=- ===-- http://arcgraph.de/sr/
|  |