Paul Mackerras wrote:
If a soft irq is raised in process context, raise_softirq() in kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd runs soon to process the soft irq. So what would happen is that we would see the TIF_RESCHED_PENDING flag on the current task in the syscall exit path and call schedule() which would switch to ksoftirqd to process the soft irq (if it hasn't already been processed by that stage).
I think I see a problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set (and maybe doing other stuff if there are no messages). Under the scenario you described, schedule() would re-run the spinning task, no? This could prevent any incoming packets from actually being sent up the stack until we get a real hardware interrupt--which could be a whole jiffy if interrupt mitigation is enabled in the net device.
Chris _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
