Re: [linux-audio-dev] user lowlatency kernel experience

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] user lowlatency kernel experience
From: John Regehr (regehr_AT_cs.utah.edu)
Date: Thu Jun 14 2001 - 02:10:04 EEST


On Wed, 13 Jun 2001, Paul Davis wrote:

> >so, since people here seem to think that the low-latency kernel is
> >really great, i suspect i have missed something. is there a way to get
> >processes to get sceduled promptly, but at the same time not hog the cpu
> >if they try?
>
> welcome to the complex world of RT-scheduled cooperating apps.
>
> the short answer is no.
>
> the long answer is that the apps have to be written to cooperate, and
> that since they are not written to cooperate, they need to be run by a
> scheduler that understands what to do. this has a lot to do with the
> LAAGA discussion now under way on this list.

The short answer to the original question is "it's easy, but not with a
fixed-priority scheduler".

The long answer is that during the past decade or so there has been a
ton of work on supporting concurrent, independently written real-time
applications in real-time and general-purpose operating systems.

A number of schedulers that can accomplish this are available for Linux.
One of them is Linux/RT (not to be confused with RTLinux) and can be
found at this site:

http://www.timesys.com/

To use one of these schedulers, each real-time thread is assigned a CPU
reservation. For example, 1ms/10ms or 46ms/522ms. As long as the total
utilization is less than one (ignoring overhead) all real-time threads
will receive the reserved amount of CPU time during each period. Of
course, it can be hard to know how much time to reserve, but if your
application is not particularly demanding you can just overestimate and
everything will work fine.

The whole idea of using a priority-based scheduler (like Linux's) to
schedule real-time applications is based on the assumption that
applications can be trusted not to hog the CPU. When this assumption is
false (and in other cases when application authors do not cooperate) a
different kind of scheduler is required.

John


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jun 14 2001 - 04:06:38 EEST