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: Herbie Robinson <email@hidden>
- Date: Sat, 8 May 2004 03:58:44 -0400
At 7:05 AM -0400 5/7/04, David Duncan wrote:
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.
Actually, that's far from universally true. Many OS developers claim
vociferously that maintaining LRU in a paging system isn't cost
effective and that randomly shooting pages works just as good without
the overhead of maintaining LRU. They do have performance data to
back the claims (although, it does sound fishy to me....).
If LRU isn't being used, then the only information available is
whether a page has been touched since the last time the the
use/modified bits were reset. If you are doing real-time on that
kind of a system, you are going to be OK as long as there are totally
unused pages around to flush out, but once those are all gone, the
system can only pick pages at random to flush. When that happens, it
doesn't matter how frequently the memory was accessed, any thread
could become a victim.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.