Re: 2.6.X, NPTL, SCHED_FIFO and JACK

[Peter Williams <pwil3058@bigpond.net.au>]

Takashi Iwai wrote:
> 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...

Version 1.4 of the various SPA schedulers (for 2.6.7) are available for 
download at <https://sourceforge.net/projects/cpuse/>.  In this 
modification I have attempted to minimize the scheduling overhead costs 
for SCHED_FIFO tasks.  I would appreciate any feedback on how successful 
I have been.

Thanks
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce