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

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

[Andi Kleen]

C Hanish Menon <hanishkvc@yahoo.com> writes:

>    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

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

[C Hanish Menon]

Hi Andi

Andi Kleen wrote:
> 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