This started out as a thread on the ppc list, but on the suggestion of DaveM and Paul Mackerras I'm expanding the receiver list a bit.
Currently, if a softirq is raised in process context the TIF_RESCHED_PENDING flag gets set and on return to userspace we run the scheduler, expecting it to switch to ksoftirqd to handle the softirqd processing. I think I see a possible problem with this. Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under the scenario above, schedule() would re-run the spinning task rather than ksoftirqd, thus preventing any incoming packets from 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. DaveM pointed out that if we're doing transmits we're likely to hit local_bh_enable(), which would process the softirq work. However, I think we may still have a problem in the above rx-only scenario--or is it too contrived to matter? Thanks, Chris _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
