From: Ingo Molnar <mi...@elte.hu> Date: Tue, 12 May 2009 11:23:48 +0200
>> Wouldn't the even better solution be to get rid of softirqs >> all-together? >> >> I see the recent work by Thomas to get threaded interrupts >> upstream as a good first step towards that goal, once the RX >> processing is moved to a thread (or multiple threads) one can >> priorize them in the regular sys_sched_setscheduler() way and its >> obvious that a FIFO task above the priority of the network tasks >> will have network starvation issues. > > Yeah, that would be "nice". A single IRQ thread plus the process > context(s) doing networking might perform well. Nice for -rt goals, but not for latency. So we're going to regress in this area again? I can't see how that's so desirable, to be honest with you. The fact that this discussion started about a task with a certain priority not being able to make forward progress, even though it was correct coded, just because softirqs are being processed in a thread context, should be a big red flag that this is a buggered up design. I fully expected us to be, at this point, talking about putting the pending softirq check back into the trap return path :-/ _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
