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

[Ingo Molnar <mingo@elte.hu>]

* William Weston <weston@sysex.net> wrote:

> Jackd (-R -P64 -dalsa -dhw:0 -r44100 -p64 -n3 -i2 -o2) w/ one
> soft-synth client (using 15% to 30% of the CPU) will run for over 12
> hours without any xruns, even during kernel compiles and nightly
> updatedb runs.
> 
> 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.

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

It should look like this in the Kernel Hacking menu of menuconfig:

       [*] Wakeup latency timing
       [ ] Non-preemptible critical section latency timing
       [ ] Interrupts-off critical section latency timing
       [*]   Latency tracing

what is the longest wakeup latency the tracer shows? You can start the
measurement anew via:

	echo 0 > /proc/sys/kernel/preempt_max_latency

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.)

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.

> 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 {