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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
