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

[Mark Knecht <markknecht@gmail.com>]

On 1/10/06, Steven Rostedt <rostedt@goodmis.org> wrote:
> 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

Steven,
   No, this specific machine is UMP although I do have an HT machine I
use once in awhile that might fall prey to what you are mentioning.

   While I have to agree that *if* cdrecord is running at a higher
priority then Jack would get trumped, I'm not positive yet that we
know that's true in this specific case. I have not yet received any
response from the developer of k3b, and while cdrecord is listed in
the setup of k3b I'm not sure how to test that it is really causing
the specific failure I saw.

NOTE: I'm sure cdrecord probably is causing this. I just don't want to
believe it is without some technical confirmation and assume there's
nothing that could be improved in the kernel.

NOTE 2: This case is pathological as I would never start writing a CD
when doing important audio work that requires zero xruns. I reported
it only to learn more myself.

Thanks,
Mark
-
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/