2009/10/22 Jörn Nettingsmeier <[email protected]> > hi everyone! > > > i just came across con kolivas' announcement of the latest release of > the brain fuck scheduler, http://lwn.net/Articles/357451/ . > > in it, he explains the idea behind isochronous scheduling (which lennart > brought up when announcing his realtime kit): > > > Isochronous scheduling. > > > > Isochronous scheduling is a unique scheduling policy designed to provide > > near-real-time performance to unprivileged (ie non-root) users without > the > > ability to starve the machine indefinitely. Isochronous tasks (which > means > > "same time") are set using, for example, the schedtool application like > so: > > > > schedtool -I -e amarok > > > > This will start the audio application "amarok" as SCHED_ISO. How > SCHED_ISO works > > is that it has a priority level between true realtime tasks and > SCHED_NORMAL > > which would allow them to preempt all normal tasks, in a SCHED_RR fashion > (ie, > > if multiple SCHED_ISO tasks are running, they purely round robin at > rr_interval > > rate). However if ISO tasks run for more than a tunable finite amount of > time, > > they are then demoted back to SCHED_NORMAL scheduling. This finite amount > of > > time is the percentage of _total CPU_ available across the machine, > configurable > > as a percentage in the following "resource handling" tunable (as opposed > to a > > scheduler tunable): > > > > /proc/sys/kernel/iso_cpu > > > > and is set to 70% by default. It is calculated over a rolling 5 second > average > > Because it is the total CPU available, it means that on a multi CPU > machine, it > > is possible to have an ISO task running as realtime scheduling > indefinitely on > > just one CPU, as the other CPUs will be available. Setting this to 100 is > the > > equivalent of giving all users SCHED_RR access and setting it to 0 > removes the > > ability to run any pseudo-realtime tasks. > > > > A feature of BFS is that it detects when an application tries to obtain a > > realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the > > appropriate privileges to use those policies. When it detects this, it > will > > give the task SCHED_ISO policy instead. Thus it is transparent to the > user. > > Because some applications constantly set their policy as well as their > nice > > level, there is potential for them to undo the override specified by the > user > > on the command line of setting the policy to SCHED_ISO. To counter this, > once > > a task has been set to SCHED_ISO policy, it needs superuser privileges to > set > > it back to SCHED_NORMAL. This will ensure the task remains ISO and all > child > > processes and threads will also inherit the ISO policy. > > this looks like it could provide a simple way of granting fixed-deadline > tasks appropriate cpu time without effectively handing the machine over. > i was quite skeptical of lennart's idea of a userspace daemon to do the > job reliably, but the scheduler should have pretty good leverage on > rogue tasks :) > > has anyone tried the bfs for audio yet? > > > best, > > > jörn >
Everything's smooth, ultra responsive. It finally feels like I have a desktop. I've been on it for 2 weeks already, and never been better (doing the same audio tasks I do). But for some people, they may get more xruns than with a true RT kernel. For others, may not even be an option due to hardware. http://schivmeister.wordpress.com/2009/09/28/linux-audio-to-rt-or-to-bfs/
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
