[linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Nick Piggin]

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin at yahoo.com.au> 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.