Hi,
On Sat, Feb 27, 2010 at 09:39:19AM +0800, Da Zheng wrote:
On 10-2-27 上午9:10, Dirk Vogt wrote:
Hej, You're right. There is indeed a problem, which we haven't stumbled over yet. That is, because the irq handler runs at at a higher priority in our ddekit implementation. However on a multiprocessor machine this
I don't understand. How can using a higher priority in the irq handler solve/avoid the problem? unless you mean running the softirq thread in a higher priority. Otherwise, the softirq thread can still be preempted and lose raised softirq as I mentioned in the previous letter.
You're right, priorities would not help on a multi-processor platform. But these scenarios are currently not supported anyway, so let's stay with one CPU. In this case DDE Linux works like the good old BSD4.4, in which the kernel execution contexts were assigned to priority levels. The interrupts on the higher levels and the user contexts on the lower ones. This scheme guarantees that interrupt contexts always finish their execution before other lower-priority contexts are executed. Linux adopted this in a way.
Anyway, any approach that relies on priorities regarding DDE (or paravirtualization at large) on a microkernel caused problems in the past. Therefore, we discuss better options.
problem would indeed occur. We recognized the problem and are currently discussing solutions. One Solution would be to have one Soft-irq thread for each irq. You can expect a fix for this soon. If mach supports it
Isn't it the current implementation? In DDE, each driver has one irq and one softirq thread?
That's not completely correct as DDE Linux does not prevent to run various drivers linked together in one protection domain. This may end up with multiple interrupt or softirq threads.
and you are using a single core machine a suggest to raise the prio of the irq handler thread in the ddekit as workaround.
In my current porting, I already raise the priority of the irq handler, but it doesn't solve the problem.
I am thinking of using a lock to simulate cli/sti. When local_irq_enable() or local_irq_save() is called, we hold the lock; when local_irq_restore() or local_irq_disable(), we release the lock. We can even provide nested locking support if local_irq_enable() or local_irq_save() is allowed to be called multiple times in the same thread.
I think this addresses our issue in a way: Prevent handling of the just registered softirq until the interrupt handler returns. Afterwards, the registered softirq can be handled from the standard softirq thread as long as the queue manipulation is atomic. The issue is now near the top of our agenda for DDE.
Greets