CODEWITHSUNDEEP
linux-kernelinterrupt-handling
user2526111
user2526111

Reputation: 474

Preemption among SOFTIRQ context

I have a system which has following config;

When SOFTIRQ 1 is running, Interrupt B comes and then ISR B kicked in. When irq_exit() happens at ISR B, it will invoke softirq. So, it will schedule SOFTIRQ 2 (without taking care of SOFTIRQ 1 which was interrupted).

Is it right statement?

Another question. At this moment, if SOFTIRQ 1 disabled "bottom_half", where we dectect bottom half is disabled and skipped SOFTIRQ 2's execution? Thanks in advance!

Upvotes: 2

Views: 2364

Answers (1)

Peter Teoh
Peter Teoh

Reputation: 6753

Perhaps you have confused between SOFTIRQ and HARDIRQ. Softirq in Linux kernel is the "bottom_half" in IRQ processing, which is scheduled by the task scheduler for execution to handle delayed IRQ processing. And during this processing, it can potentially handle multiple delay IRQ processing, say IRQ A and IRQ B in your case.

But if any IRQ enters into the system, it will trigger the ISR handler, and there is no immediately triggering of any SOFTIRQ, only being scheduled for later processing, not "invoke" as your wording says. (ie, all hardware IRQ handler are not supposed to call raise_softirq(), but schedule a handler for IRQ processing)

So in summary, for your scenario:

After ISR B have ended, it may submit SOFTIRQ B for later processing - but it is NOT calling raise_softirq(). But since SOFTIRQ A have been intercepted half-way, after any hardware interrupt it will continue the last tasks before, and so SOFTIRQ A will execute to completion.

To elaborate on raise_softirq() internal, which call raise_softirq_irqoff():

inline void raise_softirq_irqoff(unsigned int nr)
{
        __raise_softirq_irqoff(nr);

        /*
         * If we're in an interrupt or softirq, we're done
         * (this also catches softirq-disabled code). We will
         * actually run the softirq once we return from
         * the irq or softirq.
         *
         * Otherwise we wake up ksoftirqd to make sure we
         * schedule the softirq soon.
         */ 
        if (!in_interrupt())
                wakeup_softirqd();
}

As the comment goes, if you are inside softirq A and IRQ B comes in, IRQ B processing will end - to be re-run after it finishes the current SOFTIRQ A.

To emphasize that all hardware does not call "raise_softirq()", a search of linux kernel yield the following result (none is from hardware, which is from the "drivers" branch):

enter image description here

And in the networking IRQ handler - the napi_schedule() is called. (In general search for "sched" inside all drivers IRQ handler). The following is from drivers/net/usb/r8152.c:

enter image description here

Upvotes: 5

Related Questions