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: Stéphane Letz <email@hidden>
- Date: Fri, 7 May 2004 10:08:48 +0200
It isn't just vecLib. It's pretty much any dynamically loaded
framework,
which is just about all of them. If you step into a vecLib call in gdb
the
first time it is called, you may find yourself buried in the guts of
dyld
to do the dynamic linking. The actual overhead of initializing vecLib
is
pretty small. The code has to be paged in too of course, so its
non-trivial if you have immediate real time needs.
If a understand correctly the different answers (Doug Wyatt, William
Stewart...) it seems that the situation is not clear at all!
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?
When pages are allocated by the system by valloc, they arrive in a
paged
out state. When you touch them the first time a VM fault happens and
the
page is zero filled and then you can use it. malloc of sizes >= 16kB
fall
back to valloc. Calloc probably does something similar. These sizes are
subject to change according to the performance characteristics of the
small allocation malloc du jour, so don't depend on your malloc
allocated
memory arriving page aligned or zeroed for large blocks. If you want
resident memory, the best bet is to step through the array at 4 kB
intervals reading bytes. If you want zeroed memory, call calloc().
http://developer.apple.com/documentation/Performance/Conceptual/
ManagingMemory/Tasks/MemoryAlloc.html
Why is memory allocated paged out rather than paged in? It turns out
that
a lot of the time apps allocate memory and then never use it. Why evict
useful pages from RAM to make room for ones that are never used just
because someone called malloc?
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?
Stephane Letz
_______________________________________________
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.