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

Nick Piggin nickpiggin at yahoo.com.au
Thu Jul 22 22:11:47 UTC 2004


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

> Also, it's not really a performance issue if the system is idle then can
> switch to ksoftirqd cheaply (lazy-TLB) and once we switch away from
> ksoftirqd it costs as much as switching away from the idle task.

Yeah you are probably right.



More information about the Linux-audio-dev mailing list