My colleagues and I have been working on a new approach to general-purpose real-time scheduling that may be of interest to the Linux audio community.
I hope some developers here may find it interesting.
We are able to achieve ~1ms range scheduling response even during persistent 100% system load. This represented significant improvements over Linux's CFS and real-time schedulers (see paper and slide links below). That's the good news. The bad news is that we do introduce a new system call, and we require real-time applications to be modified to use the interface. In the paper, we describe how the interface is used in our own video player as well as a modified version of the X.Org X11 server.
How does our approach work (briefly?)
Our approach combines fair scheduling and real-time. We use a new system call "coop_poll()" that is used by application event loops to rendezvous with the kernel, and to share essential timing information (a "release-time") with the kernel scheduler. The kernel scheduler wakes the task up (i.e. return from coop_poll) at the application specified time. When returning, coop_poll provides timing information from the rest of the sytem (kernel and other cooperative tasks). And the whole cycle repeats---the thread later calls coop_poll to yield back to the kernel at appropriate time, in return the kernel scheduler resumes the thread very quickly when its own "release-time" arrives. Aside from short timeslices around release-time, the scheduler timeslices, divides CPU time, among tasks according to a fair queuing approach. Tasks that behave well (use the coop_poll interface as just described) will receive very low latency execution at release-times, and overall fair share of CPU over time otherwise. Our kernel scheduler provides enforcement, so a task that attempts to abuse the interface will lose low-latency execution, although it may regain it if the abuse is not persistent. All tasks receive (weighted) fair CPU allocation. There is no need for root or real-time privilidges.
We presented the work earlier this year at the EuroSys 2009 conference: