Re: real-time threaded IO with low latency (audio)
David Olofson (audiality@swipnet.se)
Sat, 24 Jul 1999 18:12:11 +0200
Oliver Xymoron wrote:
>
> On Sat, 24 Jul 1999, Ingo Molnar wrote:
>
> >
> > On Fri, 23 Jul 1999, Oliver Xymoron wrote:
> >
> > > Exactly. But it has never been intended to be a realtime system in the
> > > true sense of the word. Nor is that something we want to aim for. Consider
> > > for a moment that systems like QNX don't implement things like the page
> > > faulting half of virtual memory (though they still have separate address
> > > spaces) and ask yourself why they don't even in 1999 and you might begin
> > > to understand why there will never be an absolute guarantee on latency in
> > > Linux. Our average performance will be better though.
> >
> > i agree that we are far from being RT, but i can see no contradiction
> > between having page-faultable virtual memory and soft-RT (or even
> > hard-RT). Obviously the RT process wants to use mlock().
>
> The problem is virtual memory overcommit - the time it takes to find a
> free page can be more or less unbounded. It's still possible to make a
> Linux box thrash, after all. Also, latency of page-in is a problem and all
> the lazy mapping that Linux does means that faults can occur at unexpected
> points and make a mess of things. Fault on the stack, for instance, and
> things get a little messy.
Hmmm... mlockall() seems to do what I want... (Probably even overkill.
mlock() should be able to do the job, and not locking non RT stuff.) Or
does man 2 mlockall lie? (About the stack.)
> On an unloaded system, yes, you can be clever with mlock() and pre-fault
> everything before going into your critical code, but the people who are
> begging for RT performance for multimedia stuff don't understand that it
> means running with basically no load and giving up tons of memory and not
> touching the disk, etc..
Unloaded system? Not good enough. How to do multitrack hard disk
recording then?
In theory, it's no problem separating RT from non RT, and RTLinux
already does so, and works in real life. As long as the CPU, the RAM and
the hardware directly involved doesn't disappear in a cloud of smoke
every now and then, RT performance will be delivered.
Hacking a nice solution is another matter...
//David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/