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

[William Weston]

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>

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