Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Ingo Molnar (mingo_AT_elte.hu)
Date: Thu Jul 22 2004 - 19:23:57 EEST
* 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.
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.
Ingo
This archive was generated by hypermail 2b28 : Fri Jul 30 2004 - 10:24:57 EEST