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

[Nick Piggin <nickpiggin@yahoo.com.au>]

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>>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
> 
> 
> no, i'm referring to this one:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-I1
> 
> (disregard the debugging induced complexity.)
> 

OK... help me out here, you are referring to this:

+/*
+ * Preempt a softirq context if necessary:
+ */
+int cond_resched_softirq(void)
+{
+	BUG_ON(!in_softirq());
+	if (softirq_need_resched()) {
+		__local_bh_enable();
+		__cond_resched();
+		local_bh_disable();
+		return 1;
+	}
+	return 0;
+}

To break out of softirq processing, right?

You wouldn't need to do this to break out of interrupt context softirqs
because you wouldn't bother returning to it. Just hand the work off to
ksoftirqd.

The main thing I am looking at is getting low latency softirqs without
always handing them off to ksoftirqd. Not to mention that my patch
disables softirqs in critical regions, which can't be bad for scalability.

> 
>>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.
> 
> 
> the softirq-defer patch is just the first step to enable lock-break of
> softirqs - the lock-break is done in the -I1 patch.
> 
> (what patch do you refer to via 'my earlier one'? Did you mean your 'if
> (rt_task())' suggestion?)
> 

Well yeah, obviously it would need a bit of help before it gets there.

But I'll shut up for now because I'm not the one doing all the coding :)
It seems like you're getting good results.