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

[Nick Piggin]

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/