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

[Ingo Molnar <mingo@elte.hu>]

* Scott Wood <scott@timesys.com> wrote:

> > if both hardirqs and softirqs are redirectable to process contexts then
> > the only unpredictable latency would be the very short IRQ entry stub of
> > a new hardirq costing ~5 usecs - which latency is limited in effect
> > unless the CPU is hopelessly bombarded with interrupts.
> 
> Those aren't the only sources; you also have preempt_disable() and
> such (as well as hardware weirdness, though there's not much we can do
> about that).

i did not say latency sources, i said unpredictable latency sources. 
hardirq and softirq processing introduces near arbitrary latency at any
(irqs-enabled) point in the kernel. Hence they make all kernel code
unbound in essence - even the most trivial kernel code, sys_getpid().

by (optionally) moving softirqs and hardirqs to a process context we've
removed this source of uncertainty by making all processing synchronous,
and what remains are ordinary algorithmic properties of the kernel code
- which we can predict and control. I.e. with those two fixed we now
have a _chance_ to guarantee latencies.

[the only remaining source of 'latency uncertainty' is the small
asynchronous hardirq stub that would still remain. This has an effect
that can be compared to e.g. cache effects and it cannot become unbound
unless the CPU is bombarded with a very high number of interrupts.]

> > to solve the spinlock problem of hardirqs i'd propose a dual type
> > spinlock that is a spinlock if hardirqs are immediate (synchronous) and
> > it would be a mutex if hardirqs are redirected (asynchronous). Then some
> > simple driver could be converted to this RT-aware spinlock and we'd see
> > how well it works. Have you done experiments in this direction? 
> 
> This sort of substitution is what we did in 2.4, though we made this
> type the default and gave the real spinlocks a new name to be used in
> those few places where it was really needed.  Of course, this resulted
> in a lot of places using a mutex where a spinlock would have been
> fine.

what are those few places where a spinlock was really needed?

I'm a bit uneasy about making mutexes the default not due to performance
but due to e.g. some hardware being very timing-sensitive. I dont think
we can make a blanket assumption that every code path is preemptable if
all processing is synchronous and the exclusions are listened to.

	Ingo