* Nick Piggin <[EMAIL PROTECTED]> wrote:
this doesnt work either: once we've committed ourselves to do an 'immediate' softirq processing pass we are risking latencies. We cannot preempt the idle task while it's processing softirqs the same way we can do the lock-break if they are always deferred.
It is a preempt off region no matter where it is run. I don't see how moving it to ksoftirqd can shorten that time any further.
look at my latest patches to see how it's done. We can preempt softirq handlers via lock-break methods. The same method doesnt work in the idle
Are you referring to this patch? http://people.redhat.com/mingo/voluntary-preempt/defer-softirqs-2.6.8-rc2-A2
Surely something similar could easily be done for irq context softirq processing with a patch like my earlier one? And it would prevent spilling to ksoftirq when a RT thread isn't waiting to run.
thread. With this method i've reduced worst-case softirq latencies from ~2-4 msecs to 100-200 usecs on a 2GHz x86 box.
Nice numbers.
