12 Jul
2004
12 Jul
'04
10:36 p.m.
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
No, this is wrong. 2.6+preempt can satisfy your latency requirements
without any scheduling points. All it requires is that the long-held locks
be addressed. I've already done a metric ton of work in that area (notably
removal of the buffer_head LRUs and rewriting the truncate code) but more
apparently remains to be done. We know that reiserfs has problems.
But what can I do? I set up a preempt-on-ext3 test box, thrash the crap
out of it and see 300 usecs worst-case latency. So I am left empty-handed,
wondering what on earth is happening out there.
I am deeply skeptical about claims that autoregulated swappiness can make
any difference.
I am deeply skeptical about claims that CPU scheduler changes make any
difference. A scheduler change shouldn't improve responsiveness of
!SCHED_OTHER tasks at all, so perhaps there are application priority
inversion problems, or applications aren't setting SCHED_FIFO/RR correctly.
I do not know.
I am also fairly skeptical about claims that voluntary-preempt helps,
because it only pops a couple of locks, and I doubt that testers are
hitting the code paths which those changes address anyway.
So Something Is Up, and I don't know what it is.
Please double-check that there are no priority inversion problems and that
the application is correctly setting the scheduling policy and that it is
mlocking everything appropriately.
And please ensure that people are setting xrun_debug, and are sending
reports.
It's too bad that the multimedia community
didn't participate
much during the 2.5.xx development leading up to 2.6.0. If they
had done so, the situation might be different today. Fortunately,
fixing up the multimedia problems isn't too risky to do during
the stable 2.6.xx series.
I regret that this description is persisting here. "We" (the audio
developer community) did not participate because it was made clear
that our needs were not going to be considered. We were told that the
preemption patch was sufficient to provide "low latency", and that
rescheduling points dotted all over the place was bad engineering
(probably true). With this as the pre-rendered verdict, there's not a
lot of point in dedicating time to tracking a situation that clearly
is not going to work. The kernel is not going to provide adequate latency
for multimedia
needs without either (1) latency issues being front and center in
every kernel developer's mind, which seems unlikely and/or (2)
conditional rescheduling points added to the kernel, which appears to
require non-mainstreamed patches.
Nope, the conditional rescheduling points provide zero benefit on a
preemptible kernel.
Something weird is happening, I don't know what it is, I cannot reproduce
it and I need help understanding what it is, OK? The sooner we can do
that, the sooner it gets fixed up.