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: Fri, 7 May 2004 07:05:09 -0400
On May 7, 2004, at 04:08 AM, Stiphane Letz wrote:
If a understand correctly the different answers (Doug Wyatt, William
Stewart...) it seems that the situation is not clear at all!
I don't think the answers were different at all. They all basically
said that Mac OS X pages in on first use for most allocations (be they
for code or data) so if you are worried about taking a page hit you
should make sure the code or data is loaded before you hit the realtime
thread.
In any event, warming up code paths before they are needed in real
time is
a useful technique!
How can you do that? It there a *general* technique? Do you need to
know in advance where the code will be mapped and warm it?
No, just call the function.
On linux and some other Unix OS's, the buffer cache will, by
default, expand to consume RAM. it may force paging of code/data that
hasn't been used recently. What is the situation on MacOSX?
If code/data hasn't been used in a while, it is more likely to be
victimized than if it was just used, just like most other VMs. There
are a lot of details, and it looks like it would help you to read the
available documentation.
Performance Documentation:
http://developer.apple.com/documentation/Performance/Performance-
date.html
Specifically, I think you will want to read the Fundamentals section
and the Memory Performance section.
--
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.