Messages in this thread |  | | | Date | Thu, 22 Jul 2004 20:54:09 +1000 | | From | Nick Piggin <> | | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch |
Ingo Molnar wrote: > * Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > >>Given that we're looking for something acceptable for 2.6, how about >>adding >> >>if (rt_task(current)) >> kick ksoftirqd instead >> >>Otherwise, what is the performance penalty of doing all softirq >>processing from ksoftirqd? > > > 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. Maybe just the simple approach of "if you care about hard latency then let ksoftirq do everything" is best? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |