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: Ian Ollmann <email@hidden>
- Date: Thu, 6 May 2004 20:08:45 -0700
Doug Wyatt wrote
>
- 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.)
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.
In any event, warming up code paths before they are needed in real time is
a useful technique!
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?
Ian
---------------------------------------------------
Ian Ollmann, Ph.D. email@hidden
---------------------------------------------------
_______________________________________________
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.