Skip to contentSkip to conversation

Seems like a race or unhandled situation with ksoftirqd scheduling/management

DISCUSSION Andi Kleen 2 participants 2 messages May 21, 2002 1 message not in the archive

lore
Share & tools
lore

Andi Kleen

author
#1 lore raw
In reply to a message not in the archive
Quoted 6 lines · C Hanish Menon

According to the comment in cpu_raise_softirq it doesn't
wakeup_softirqd in irq context because on returning from a irq softirqd will be run, but it doesn't seem to be valid in any architectures (have varified x86, mips). Because on returning from irq context, just the scheduler gets called, but as the ksoftirqd is not in the run queue, it won't get scheduled.

At least i386 runs the softirqs at the end of do_IRQ.

ksoftirqd is just supposed to be a fallback mechanism for the case of soft irqs eating excessive runtime or one softirq triggering another (common case is networking and serial softirq for BH). It is not the primary way to run softirqs.

-Andi

#2 lore raw

Re: Seems like a race or unhandled situation with ksoftirqd scheduling/management - Oops missed the control flow in the generic irq.c as most targets use their own irq.c

In reply to a message not in the archive

Hi Andi

Quoted 6 lines · Andi Kleen

At least i386 runs the softirqs at the end of do_IRQ.

ksoftirqd is just supposed to be a fallback mechanism for the case of soft irqs eating excessive runtime or one softirq triggering another (common case is networking and serial softirq for BH). It is not the primary way to run softirqs.

Oops, You are right, i386 and also the generic mips irq.c has code in do_IRQ to call do_softirq.

But most of the target specific irq.c in mips, don't seem to follow this convention. Even when I started my port, I had based my interrupt subsystem after looking into some of these target specific irq.c's.

So I was expecting this call to softirqs occuring from within kernel/entry.S after ret_from_irq. And as there is no code there to this end, I came to my flawed conclusion.

Sorry about this wrong assumption.
I have got the solution to my problem. However have to check out with the mips target guys has to how they are taking care of softirqs. When they aren't calling do_softirq from do_IRQ or any other part of interrupt subsystem.

Keep :-)
HanishKVC