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

[Rui Nuno Capela]

Ingo Molnar wrote:
>
> 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?
>

Did I mention that the XRUNs seem to occur only when xmms-jack is in the
graph? AFAICT xmms-jack uses a sort of double-buffering wrapper
(bio2jack), or in other words, its not a "native" jack client.

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

Yes, and I'll have to rebuild a new RT-V0.7.31-19 kernel without latency
timing stuff, just to make sure we'll compare apples to apples ;)

Bye now.
-- 
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx

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