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.