* Nick Piggin <[EMAIL PROTECTED]> 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.
