Messages in this thread | | | Date | Sat, 24 Jul 1999 18:12:11 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
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/
| |