Re: [linux-audio-dev] [Slightly OT] How to access "real-time" capabilities

On Thu, 9 Jun 2005 08:29:21 +0200
asbjs@email-addr-hidden (Asbjørn Sæbø) wrote:

> On Wed, Jun 08, 2005 at 11:20:18AM -0500, Jack O'Quin wrote:
> > asbjs@email-addr-hidden (Asbjørn Sæbø) writes:
>
> [...]
> > > * If given a real-time kernel, what else is necessary to take advantage
> > > of its capabilities?
> >
> > Your realtime thread needs to use one of the POSIX realtime scheduling
> > options: SCHED_FIFO or SCHED_RR. For best results, only do this for
> > the code that actually *needs* precise timing.
>
> Thanks! Bear with me, please, but this is still not totally clear to
> me. This is something that is done in the code, as it is written, is
> that correct? It is not something you can do to an already written
> program?
>
> Or, in other words: Is there a way to have an already written/compiled
> program to achieve realtime scheduling?

You can set certain threads to SCHED_FIFO with i.e. the chrt program
from the schedutils package. But usually an app needs to be designed to
use this scheduler class.

BTW: SCHED_FIFO is not something which is only available in RP kernels.
It's a POSIX specified scheduling class and its feature is that the
scheduler will never take the cpu away from a SCHED_FIFO thread as long
as

[1] it doesn't give it up voluntarily

[2] there's no other runnable SCHED_FIFO (or SCHED_RR) thread with higher
priority.

So a simple while(1) { //foo } that does never quit is enough to block
all other processes from ever being executed (and thus seemingly hang
your box).

As i said this is not a feature exclusive to RP kernels, but you can do
that even with a vanilla kernel. Normally non privileged processes
cannot aquire SCHED_FIFO by themself. Thus people use the rtlimit or the
realtime-lsm to grant these privileges to normal user programs.

Ok, so what does the RP kernel do for realtime sensitive programs then?
Basically two things:

[1] decrease the length of non preemptible code paths in the kernel by
making practically everything preemptible. This reduces the time it
takes, for example, to run a SCHED_FIFO thread after the interrupt it
waits for has happened (if it's the highest priority runnable thread in
the system the maximum delay experienced from non preemptible code paths
in a RP kernel is in the microseconds range).

[2] split the interrupt handling routines into a new top level handler
which is very very short and a handler thread that runs SCHED_FIFO with
a certain priority (which can be user changed). With this you can give
priorities to your interrupts i.e. if you want that your soundcard irq
shall be handled with the highermost priority in the system set its irq
handler priority to something higher than all other IRQ handler threads
and processes in your system. A typical jack setup on a RP system
usually looks like this:

keyboard irq: 99 (to get to magic sysrq in the case of an emergency)
rtc irq: 98 (used for midi timing in some applications)
soundcard irq: 97

jackd prio: 70 (its watchdog will run prio 80 then)

all other irq's and processes below 70. i usually leave them at the
defaults around 50. This way any disk activity can never disturb the
soundcard operation.

btw: i don't know if all this info helps you at all. Why don't you tell
us a bit more about your problem domain and we can try to figure out
how/if RP kernels can help you with it..

-- 
Palimm Palimm!
http://affenbande.org/~tapas/