A question about the softirq implementation in DDE Linux26

Da Zheng zhengda1936 at gmail.com
Fri Feb 26 15:08:17 CET 2010


Hi,

On 10-2-26 下午9:17, Dirk Vogt wrote:
> Hi,
>  
>   the DDE models a SMP-like setup, whereas each ddekit_thread is
> supposed to run on a dedicated CPU.  For each IRQ, there is a dedicated
> ddekit_thread.
>    As far as I understand it, disabling hard IRQs in any other
> ddekit_thread than the IRQ-handler threads has no effect, because they
> won't receive IRQs anyway.  For an IRQ handler thread, it also has no
> effect, because it only runs when it is handling an interrupt, and won't
> receive any further IRQs while handling one.
I was talking about synchronization between hard IRQ handler and softirq handler.

When the driver receives a hard IRQ, it tries to raise softirq.
    local_irq_save(flags);
    list_add_tail(&n->poll_list, &__get_cpu_var(softnet_data).poll_list);
    __raise_softirq_irqoff(NET_RX_SOFTIRQ);
    local_irq_restore(flags);
The softirq thread, on the other hand, does
    local_irq_save(flags);
    if (local_softirq_pending())
        __do_softirq();
    local_irq_restore(flags);
In __do_softirq, it does
        unsigned long pending = local_softirq_pending();

        /* reset softirq count */
        set_softirq_pending(0);

In Linux local_irq_save() disables irqs in the local processor, so if the hard
IRQ handler tries to raise softirq, it is guaranteed that the softirq thread
will not be scheduled to run, and vice versa. Since DDE doesn't disable IRQs in
the local processor, there is a possibility that __do_softirq gets the pending
softirq and then the cpu schedules to run the hard IRQ interrupt, which raise a
softirq, and then the cpu is scheduled to run the softirq thread again and runs
set_softirq_pending(0). The raised irq is just lost.

Unless I am mistaken, I think it is what causes my problem.

Best regards,
Zheng Da




More information about the l4-hackers mailing list