Re: 2.6.X, NPTL, SCHED_FIFO and JACK

[Takashi Iwai]

At Fri, 2 Jul 2004 00:37:49 -0700,
William Lee Irwin III wrote:
> 
> On Thu, Jul 01, 2004 at 01:03:56PM -0500, Matt Mackall wrote:
> >>> I'm afraid these "brave souls" have shown up to the baby shower after
> >>> the child's been accepted to college. Developers getting around to
> >>> testing 2.6 after multiple vendors are shipping it should not be
> >>> characterized as courageous.
> 
> On Thu, Jul 01, 2004 at 11:27:28PM -0400, Paul Davis wrote:
> > I call BS on this response.
> > We were told by A(ndrew)M(orton) and several other people that 2.6
> > would not be as good as 2.4 for low latency real time audio. It was
> > made clear that the preemption patches were considered more
> > appropriate even though they did not do anywhere near as reliable an
> > improvement as AM's lowlat patches. We found out (and I mean no
> > discredit to AM whatsoever - he did an amazing job on the 2.4 lowlat
> > patches) that the author of the premiere lowlat patches for 2.4 would
> > not be maintaining a similar set for 2.6. We also found during the
> > development of 2.5 that there were a number of areas of real concern,
> > (the VM subsystem and the scheduler and the disk subsystems) but that
> > many notable kernel developers were not particularly interested in our
> > needs - we were considered odd, edge case studies.
> 
> Not only are lowlat-alike changes in mainline 2.6, the algorithms where
> lowlat found explicit preemption points were necessary have been changed
> in a number of cases to be asymptotically faster.
> 
> So you gave no feedback. What do you expect us to do? There are
> enough other bugreports to keep us busy without testing the known
> universe on behalf of you or anyone else sitting around waiting
> silently for their needs to magically be addressed.

Well, the point is that no kernel developer is watching and working on
low-latency fixes regulariy for 2.6 kernels, as Andrew did for every
2.4 release.  And, the users can't report easily what gets wrong.
(If the report were something like '2.6.x worked but 2.6.y not', it
 would be easy to figure out, but many users experience this problem
 between 2.4 and 2.6...)

Maybe this situation can be improved by enabling the xrun_debug proc
switch on ALSA, which shows the stack trace when a buffer
over/underrun happens.  Also, running a latencytest program would be
helpful for spotting out the problem.


BTW, 2.6 kernel works pretty well on my system.  Perhaps it's because
I run jackd directly as root.

I've also heard some people complaining after replacement with 2.6,
too, but I believe it's either driver-specific problem or a bug caused
by the NPTL incompatibility reported on this thread.
AFAIK, there are still some problematic parts, for example, a long
lock in shrink_dcache_parent(), and too-long RCU jobs in a tasklet,
but they are relatively minor. 


> In summary:
> (1) please try to present adequate information directly
> 	-- describe your situation directly instead of needing people
> 	-- to debug your apps for you

The problem is the incompatibility between NPTL and LinuxThreads.
As Paul pointed, if calling pthread_setschedparm() has no influence
_after_ creating the thread, it sounds like a bug to me.  This might
be a problem of glibc, not of kernel.  We don't know even it. 

Anyway, we'll need a small testcase to reproduce this problem...


--
Takashi Iwai <tiwai@xxxxxxx>		ALSA Developer - www.alsa-project.org
-
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/