Messages in this thread | | | Date | Mon, 12 Jul 2004 17:24:58 -0700 | From | Andrew Morton <> | Subject | Re: desktop and multimedia as an afterthought? |
| |
Paul Davis <paul@linuxaudiosystems.com> wrote: > > >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.
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.
> 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. - 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/
| |