2009/10/22 Jörn Nettingsmeier <span dir="ltr"><<a href="mailto:nettings@folkwang-hochschule.de">nettings@folkwang-hochschule.de</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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

<div><br></div><div><a href="http://schivmeister.wordpress.com/2009/09/28/linux-audio-to-rt-or-to-bfs/">http://schivmeister.wordpress.com/2009/09/28/linux-audio-to-rt-or-to-bfs/</a></div></div>