[LAD] BFS and lennart's realtimekit idea...

Jörn Nettingsmeier nettings at folkwang-hochschule.de
Thu Oct 22 14:23:03 UTC 2009

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?



More information about the Linux-audio-dev mailing list