Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

William Weston
2005-02-10T02:14:08Z

On Wed, 9 Feb 2005, Ingo Molnar wrote:

> > Running wmcube (an impractical, greedy, little CPU meter), even when
> > niced, causes lots of xruns. It may be good for worst-case-scenario
> > desktop load testing.
>
> this phenomenon is very weird.
>
> Firstly, make sure that all relevant threads (including the soundcard
> IRQ thread, jackd threads, jack client thread, etc.) have higher RT
> priority than any other, latency-irrelevant threads in the system.

Thanks for the tip. I have schedtool installed, and all audio/MIDI IRQ
threads, jack threads, and jack clients are now run with higher priorities
than everything else. Before I adjusted priorities, I was getting a bunch
of these when running latencytest (which have since disappeared):

rtc: lost some interrupts at 8192Hz.
bug in rtc_read(): called in state S_IDLE!

IRQ 8 (RTC) is still giving me some issues, even after adjusting
priorities:

`IRQ 8'[232] is being piggy. need_resched=0, cpu=0
Read missed before next interrupt

Should the RTC IRQ be given a new priority? If so, should it be lower,
higher, or equal to the audio/MIDI/jack priorities?

> If everything looks OK on the priority-administration side, could you
> enable wakeup-latency tracing via:
>
> CONFIG_WAKEUP_TIMING=y
> CONFIG_PREEMPT_TRACE=y
> # CONFIG_CRITICAL_PREEMPT_TIMING is not set
> # CONFIG_CRITICAL_IRQSOFF_TIMING is not set
> CONFIG_LATENCY_TIMING=y
> CONFIG_LATENCY_TRACE=y

<snip>

> what is the longest wakeup latency the tracer shows? You can start the
> measurement anew via:
>
> echo 0 > /proc/sys/kernel/preempt_max_latency

Max latency is in the realm of 13-18 after runs of jack_test4.1.

> every new maximum-latency event will be logged by the kernel, and the
> trace of the latest worst-case latency path can be found under
> /proc/latency_trace.
>
> (If the trace is very long then most of the time it's OK to just send
> the first 25 and last 10 lines. Putting the trace up to a website is a
> good solution too.)

See http://www.sysex.net/testing/ for the all of the test results and
system info on a 2.6.11-rc3-RT-V0.7.38-06 kernel.

This is from my most recent run of jack_test4.1 with wmcube and kernel
compilation running (check /testing/dmesg for more):

( sshd-5940 |#0): new 4 s maximum-latency wakeup.
( IRQ 16-1803 |#0): new 5 s maximum-latency wakeup.
( make-28375|#0): new 6 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 6 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 7 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 8 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 8 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 9 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 10 s maximum-latency wakeup.
( ksoftirqd/0-2 |#0): new 10 s maximum-latency wakeup.
( jackd-29348|#0): new 12 s maximum-latency wakeup.
( jackd-29348|#0): new 14 s maximum-latency wakeup.
( jackd-29348|#0): new 15 s maximum-latency wakeup.

> it should not matter how 'greedy' wmcube is. Does it do alot of graphics
> activity (perhaps 3D too?) - that could in theory cause hardware
> latencies - the latency traces will tell.

Wmcube displays a 3D spinning cube, which spins faster (actually performs
larger rotations between updates) when CPU usage goes up. When running
niced, wmcube uses about 1% to 4% of the CPU, adds about 1000 context
switches per second, and increases X load by 1% to 3% of the total CPU.

Now that the priorities are tuned, I get no xruns while running wmcube,
compiling a kernel, and running latencytest or jack_test4.1.

> > MIDI playback through any MPU-401 interface triggers the following
> > BUG, reported once for each outgoing MIDI event (non MPU-401 hw
> > interfaces and sw interfaces not affected):
>
> the patch below should fix this. (also included in -38-06 and later
> kernels.)
>
> Ingo
>
> --- linux/sound/drivers/mpu401/mpu401_uart.c.orig
> +++ linux/sound/drivers/mpu401/mpu401_uart.c
> @@ -316,12 +316,12 @@ static void snd_mpu401_uart_input_trigge
> /* read data in advance */
> /* prevent double enter via rawmidi->event callback */
> if (atomic_dec_and_test(&mpu->rx_loop)) {
> - local_irq_save(flags);
> + local_irq_save_nort(flags);
> if (spin_trylock(&mpu->input_lock)) {
> snd_mpu401_uart_input_read(mpu);
> spin_unlock(&mpu->input_lock);
> }
> - local_irq_restore(flags);
> + local_irq_restore_nort(flags);
> }
> atomic_inc(&mpu->rx_loop);
> } else {
> @@ -407,12 +407,12 @@ static void snd_mpu401_uart_output_trigg
> /* output pending data */
> /* prevent double enter via rawmidi->event callback */
> if (atomic_dec_and_test(&mpu->tx_loop)) {
> - local_irq_save(flags);
> + local_irq_save_nort(flags);
> if (spin_trylock(&mpu->output_lock)) {
> snd_mpu401_uart_output_write(mpu);
> spin_unlock(&mpu->output_lock);
> }
> - local_irq_restore(flags);
> + local_irq_restore_nort(flags);
> }
> atomic_inc(&mpu->tx_loop);
> } else {

This patch does fix the MIDI playback BUG I was seeing.

Best Regards,
--William Weston <weston at sysex.net>