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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Nick Piggin (nickpiggin_AT_yahoo.com.au)
Date: Thu Jul 22 2004 - 13:54:09 EEST


Ingo Molnar wrote:
> * Nick Piggin <nickpiggin_AT_yahoo.com.au> wrote:
>
>
>>Given that we're looking for something acceptable for 2.6, how about
>>adding
>>
>>if (rt_task(current))
>> kick ksoftirqd instead
>>
>>Otherwise, what is the performance penalty of doing all softirq
>>processing from ksoftirqd?
>
>
> this is insufficient too. An RT task might be _waiting to run_ and
> spending our time in a non-RT context (including the idle task) doing
> softirq processing might delay it indefinitely.
>
> what we could do is to add a rq->nr_running_rt and do the deferred
> softirq processing unconditionally if (rq->nr_running_rt). I'd still add
> a sysctl to make it unconditional for user processes too - if someone
> really cares about latency and doesnt want to make all his tasks RT.
> I'll code this up for the next version of the patch.
>

Or just if (rt_task || need_resched). Another thing that may be
worthwhile thinking about is allowing softirqs to be run directly
from interrupt if the idle thread is running, maybe with an early
exit if something becomes runnable. Although this all may be going
down the path of too much complexity.

Maybe just the simple approach of "if you care about hard latency
then let ksoftirq do everything" is best?


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jul 30 2004 - 10:24:49 EEST