Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4

[Ingo Molnar <mingo@elte.hu>]

* Rui Nuno Capela <rncbc@rncbc.org> wrote:

> OK. Here are my early consolidated results. Feel free to comment.
> 
>                                     2.6.9     RT-U3   RT-V0.4.3
>                                   --------- --------- ---------
>   XRUN Rate . . . . . . . . . . .     424         8         4    /hour
>   Delay Rate (>spare time)  . . .     496         0         0    /hour
>   Delay Rate (>1000 usecs)  . . .     940         8         4    /hour
>   Maximum Delay . . . . . . . . .    6904       921       721    usecs
>   Maximum Process Cycle . . . . .    1449      1469      1590    usecs
>   Average DSP CPU Load  . . . . .      38        39        40    %
>   Average Context-Switch Rate . .    7480      8929      9726    /sec

looks pretty good, doesnt it?

how is the 'maximum delay' calculated? Could you put in a tracing hook
into jackd whenever such a ~720 usecs maximum is hit? I'd _love_ to see 
how such a latency path looks like, it seems a bit long.

It should be a relatively simple hack to jackd. Firstly, download the 
-V0.5.3 patch and enable LATENCY_TRACE, then do:

	echo 2 > /proc/sys/kernel/trace_enabled

this activates the 'application-triggered kernel tracer' functionality. 

No tracing happens by default, but tracing starts if the application
executes this function:

	gettimeofday(0,1);

and tracing stops if the application does:

	gettimeofday(0,0);

whenever the app does this (0,0) call the trace gets saved and you can
retrieve it from /proc/latency_trace where you can retrieve it. There is
no combination of these parameters that can break the kernel, so it's a
100% safe tracing facility. You can 'ignore' a latency [e.g. if it's not
a maximum] by simply not doing the (0,0) call. The next (0,1) call done
will override the previous, already running trace.

[stupid function but this combination of the syscall parameters is not
used otherwise so the latency tracer hijacks it.]

i dont know how Jackd does things, but i'd suggest to enable tracing the
first time possible when getting an interrupt - in theory this should
happen as soon as the wakeup-latency-tracer says - i.e. at most in like
30 usecs. The bulk of the remaining 700 usecs will be spent in jackd, 
and you can trace those 700 usecs.

or if you would be willing to do a little bit of ALSA hacking, you could
add this to the ALSA interrupt handler:

	#include <linux/syscalls.h>

	...
	sys_gettimeofday(0, 1);

[the attached patch implements this for ali5451.]

and do the gettimeofday(0,0) in jackd [if the latency measured there is
a new maximum]! This way tracing is turned on within the kernel IRQ
handler (i.e. as soon as possible) and turned off within ALSA. This will
enable us to see an even more complete latency path.

NOTE: there can only be one trace active at a time. So if there can be
multiple channels active at a time then this user-triggered tracer might
be less useful. Do these channels have any priority? Or if multiple
channels are necessary then you could modify the patch to only do the
(0,1) call for say channel #0:

	if (channel == 0)
		sys_gettimeofday(0, 1);

in this case the trace-off-save (0,0) call in Jackd must also only do
this for channel 0 processing! (or whichever channel you find the most
interesting.)

also, i looked at the sound/pci/ali5451/ali5451.c driver code and it has
one weird piece of code on line 988:

	udelay(100);

that adds a 100 usecs latency to the main path, for no good reason! It
also spends that time burning CPU time, delaying other processing. Could 
you add an IRQs/sec measurement too if possible, so that we can compare 
the IRQ rates of various kernels?

Also, i'd suggest to simply remove that line (or apply the attached
patch) - does the driver still work fine with that?

plus i've also got questions about how Jackd interfaces with ALSA: does
it use SIGIO, or some direct driver ioctl? If SIGIO is used then how is
it done precisely - is an 'RT' queued signal used or ordinary SIGIO? 
Also, how is the 'channel' information established upon getting a SIGIO,
is it in the siginfo structure?

	Ingo

--- linux/sound/pci/ali5451/ali5451.c.orig
+++ linux/sound/pci/ali5451/ali5451.c
@@ -33,6 +33,7 @@
 #include <linux/pci.h>
 #include <linux/slab.h>
 #include <linux/moduleparam.h>
+#include <linux/syscalls.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/info.h>
@@ -985,11 +986,11 @@ static void snd_ali_update_ptr(ali_t *co
 	pvoice = &codec->synth.voices[channel];
 	runtime = pvoice->substream->runtime;
 
-	udelay(100);
 	spin_lock(&codec->reg_lock);
 
 	if (pvoice->pcm && pvoice->substream) {
 		/* pcm interrupt */
+		sys_gettimeofday((void *)0, (void *)1); // start the tracer
 #ifdef ALI_DEBUG
 		outb((u8)(pvoice->number), ALI_REG(codec, ALI_GC_CIR));
 		temp = inw(ALI_REG(codec, ALI_CSO_ALPHA_FMS + 2));