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: Doug Wyatt <email@hidden>
- Date: Thu, 6 May 2004 12:42:21 -0700
On May 6, 2004, at 5:20, David Duncan wrote:
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.
David's right -- you shouldn't worry about getting paged out; if the
memory's getting touched regularly, it won't get paged out until the
system gets very hungry for memory.
But this does lead us to a more common and important issue to be aware
of -- taking VM faults on the render thread when your code or data is
paged *in*.
There is a way in Shark to trigger samples on VM faults, and then view
only the faults that happened on the render thread. I can dig up the
details if someone else doesn't find it first.
If you find such faults, you may find these techniques helpful in
getting rid of them:
- explicitly zero newly allocated buffers that will be accessed at
audio render time. Replacing malloc() with calloc() is one way.
- at initialization time, you might make a call to your own render
function to make sure its code and data are all in memory, although in
the AU case, arguably the host should do this. I'm not sure what hosts
are doing.
- in particular, be aware that if you use vecLib, initialization would
be a good time to make calls to any functions you use, especially if
you only call vecLib under certain circumstances (e.g. we found a case
where one unit only calls vecLib when certain parameters have certain
values, so we'd take a page fault when the parameter first took that
value and called the vecLib function for the first time. So now we
explicitly make that vecLib call during initialization to make sure
that it won't page fault later during rendering.)
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
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.