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: Fri Jul 23 2004 - 01:11:47 EEST


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.


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:27:17 EEST