> > 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.)
Assuming you read down to the part about prefaulting the stack, then yes,
it'll do what you want. But don't expect your process to have bounded
performance when the rest of the system is loaded to the point of
thrashing.
> > 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?
Memory buffers. Not hard at all. The critical part is already handled in
the sound drivers. The problem is when you want to mix stuff, filter, and
send it back out in real-time. While you may be able to do that with a
couple channels already and get acceptable results, don't expect this to
scale in application space on the current generation of machines.
-- "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/