22 Oct
2009
22 Oct
'09
11:16 a.m.
2009/10/22 Jörn Nettingsmeier <nettings(a)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):
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/
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