Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19

[Ingo Molnar <mingo@elte.hu>]

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

> Here goes attached the captured latency traces for you to check. I
> guess this time xmms-jack its at stake 'coz it was the cherry on top
> of the cake, for three times in a row :)

the latency does seem to be related to clients, as in the following
trace:

  xruntrace1-2.6.10-rc2-mm3-RT-V0.7.31-19-20041201202926.trc

jackd-16714 goes into sys_poll() at timestamp 0.850ms, and does a pipe
related wait:

   jackd-16714 00000000 0.853ms (+0.000ms): pipe_poll (do_pollfd)

and goes to sleep:

   jackd-16714 00000000 0.857ms (+0.000ms): schedule_timeout (do_poll)

almost 3 milliseconds later, at timestamp 3.404ms, the pipe related
timer expires and jackd gets scheduled again:

ksoftirq-3     00000000 3.403ms (+0.000ms): wake_up_process (run_timer_softirq)
ksoftirq-3     ........ 3.404ms (+0.000ms): ->    jackd-16714
                     [ 00000027 00000003 ]: try_to_wake_up

obviously an xrun has happened during this 2.6 msec wait:

   IRQ 5-3078  00000000 2.277ms (+0.000ms): xrun (snd_pcm_period_elapsed)

but ... this brings up the question, is this a valid scenario? How can
jackd block on clients for so long? Perhaps this means that every audio
buffer has run empty and jackd desperately needed some new audio input,
which it didnt get from the clients, up until after the xrun? In theory
this should only be possible if there's CPU saturation (that's why i
asked about how much CPU% time there was in use).

One indication that this might have been the case is that in the full
3.5 msecs trace there's not a single cycle spent idle. But, lots of time
was spent by e.g. X or gkrellm-4356, which are not RT tasks - so from
the RT task POV i think there were cycles left to be utilized. Could
this be a client bug? That seems a bit unlikely because to let jackd
'run empty', each and every client would have to starve it, correct?

anyway, your plan to try jack_test3.1 again looks like the correct
approach: we first need to check the behavior of 'trivial clients',
before more complex scenarios with real clients can be considered.

	Ingo