A question about the softirq implementation in DDE Linux26

Christian Helmuth christian.helmuth at genode-labs.com
Sun Feb 28 13:57:43 CET 2010


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
-- 
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth




More information about the l4-hackers mailing list