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

[Nick Piggin]

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/