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

From: Nick Piggin
Date: Thu Jul 22 2004 - 17:14:12 EST

Ingo Molnar wrote:
* Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at