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

[Ray Rashif]

2009/10/22 Jörn Nettingsmeier <nettings at folkwang-hochschule.de>

> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091022/3108f15d/attachment.html>