Re: 2.6.15-rt2 - repeatable xrun - no good data in trace

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2006-01-10 at 11:05 +0100, Ingo Molnar wrote:
> * Mark Knecht <markknecht@gmail.com> wrote:
> 
> > > cdrecord does run with SCHED_RR/99 when started with proper privileges.
> >
> > Ah, then it's likely that this isn't a real problem and it would be 
> > expected to cause an xrun?
> > 
> > Anyway, it seems strange that the trace doesn't show anything. I 
> > suppose that's because cdrecord just grabs a lot of time at a higher 
> > priority than Jack and Jack ends up not getting serivces at all for 
> > 5-10mS?
> 
> the tracer will only detect undue delays in the 'highest prio' task in 
> the system - but it cannot detect whether all priorities in the system 
> are given out properly. In this particular case it was cdrecord that had 
> the highest priorities, and the delays you saw in Jackd were due to 
> cdrecord trumping Jackd's priority.
> 
> One way to make such scenarios easier to notice & debug would be for 
> jackd to warn if there are tasks in the system that have higher
> priorities. (maybe it could even do it at xrun time, from a lower-prio 
> thread.)

Hmm, this reminds me. This system isn't a SMP machine is it?  SMP has
threads that run at priority 99 to handle things like swapping tasks
from one CPU to another.  These will never show up in the tracer since
they are the highest priority.  But I have seen these threads cause
latencies in some of my own code.

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/