Re: Locking pages in physical memory for real-time processes
Re: Locking pages in physical memory for real-time processes
- Subject: Re: Locking pages in physical memory for real-time processes
- From: David Duncan <email@hidden>
- Date: Thu, 6 May 2004 08:20:31 -0400
On May 6, 2004, at 07:03 AM, Stiphane Letz wrote:
After discussion with Linux guys about memory issues for real-time
processes, I was wondering what is the corrrect solution on MacOSX.
Linux developers usually use mlockall kind of call to lock pages in
physical memory for data (audio buffers) and some of them were even
thinking in locking page for the code.
Is mlockall kind of call usable on MacOSX, is is really necessary, or
can we trust the memory manager to handle that correctly? Are they any
other standard techniques ; preloding data... but maybe other ideas?
Mac OS X doesn't have an mlockall() API, just mlock() so you can't lock
everything with one call (this is probably a good thing...). But you
really should profile your application and discover if you need to lock
down the memory before you actually do so. Memory pages that are
touched often (which is usually the case with buffers used by realtime
processes like audio) are only paged out as a last resort.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.