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: William Stewart <email@hidden>
- Date: Thu, 6 May 2004 14:36:58 -0700
On 06/05/2004, at 12:42 PM, Doug Wyatt wrote:
>
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.
Generally, we expect hosts to be calling AudioUnitReset (au,
kAudioUnitScope_Global, 0) when an AU is being added and will need to
do some rendering... (Also, a "preroll" render is a good idea as
well)... CAAudioUnit in the SDK actually has calls for both of these.
Despite this I frequently see AU's page faulting on the I/O thread
despite my best attempts to have them not page fault... and I suspect
that the real culprit is the point below...
I'd have to agree with the other comments, having to lock is generally
a lack of finishing your own code - and "optimisation" should be
thought of as a process that not only evaluates your performance
sometimes, but *every* (including the first) time.
Bill
>
- 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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.