>
> 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.
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..
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/