[linux-audio-dev] NPTL and real-time sched semantics

[Paul Davis]

>Has anyone done any low-latency audio testing with the new native pthread
>implementation (comes with rh9.0 at least)...?
>
>I was just reading through [1] and noticed the following (in section 8):
>
>""Realtime support is mostly missing from the library implementation. The
>system calls to select scheduling parameters are available but they have
>no effects. The reason for this is that large parts of the kernel do not
>follow the rules for realtime scheduling. Waking one of the threads
>waiting for a futex is not done by looking at the priorities of the
>waiters.""
>
>If I've understood right, SCHED_FIFO semantics do not have any meaning
>between threads of one process if NPTL is used! Hopefully this is right,
>as it would cause quite a lot of problems (GUIs and disk i/o threads can
>freely block audio processing even though using SCHED_FIFO). :(
>
>[1] http://people.redhat.com/drepper/nptl-design.pdf

i just told penguin computing that i could not buy a machine from them
if it came with RH9. ulrich (drepper) is wrong to say "large parts of
the kernel", he is right to say "significant parts of the kernel". i
hope that linus will not release 2.6 until this is fixed.  we need to
find the right place to speak loudly about this issue.

otoh, look on the bright side. i suspect that ulrich is saying that
SCHED_FIFO is not *necessarily* obeyed, in that if more than 1 thread
is waiting on a futex, the futex code will not ensure that its the
SCHED_FIFO one (or the highest priority one in general) that is
woken. however, if you're using futexes for 1:1 communication
(typical), then this shouldn't matter. in the case of JACK, for
example, its always 1:1, and i think this would be true for
audio<->disk i/o thread communication too.

what would be *really* bad is if they actually changed the code so
that attempts to set SCHED_FIFO are not honored because they believe
they are useless. i don't know which of these is true.

--p