Re: API to get installed RAM
Re: API to get installed RAM
- Subject: Re: API to get installed RAM
- From: Quinn <email@hidden>
- Date: Mon, 25 Apr 2005 14:59:44 +0100
At 14:11 +0100 25/4/05, Andy Cave wrote:
Our application is just as clever as your OS. We monitor free
phyiscal memory and use anything 'spare' (minus a 'safety region')
to cache (more) data - makes our app fly when lots of memory is
available. When the user starts another piece of s/w, and free
phyiscal memory goes down, we reduce our caches, which makes our
application a good citizen. Just like your OS.
You might be able to get the same result by just allocating some
fixed percentage of the physical memory, and letting the VM system do
its job.
Failing that (and there's always a "failing that"; applications
always have more knowledge about the problem state than the OS, and
they can exploit that knowledge to do better caching), you /can/
monitor the system's VM behaviour and adjust your caching to match.
There are at least two metrics of interest.
o A very simple metric is the pageout count. If this starts to
skyrocket, the system is clearly under memory pressure. You can get
this value using the HOST_VM_INFO selector to host_statistics (a Mach
system call).
o This same call also returns free_count, active_count,
inactive_count, and wire_count. These are the values that make up
the pie slices in Activity Monitor.
- wire_count is memory that's taken by the kernel, and is outside of
the scope of VM.
- free_count is the pool of free pages that are immediately available
to satisfy memory requests. As I mentioned earlier, this isn't a
useful number because the system strives to keep it near a fixed
value (based on the the physical memory and the number of CPUs).
- inactive_count and active_count are the size of the active and
inaction memory queues within the system. When a page is referenced
it's moved to the front of the active list. It slowly ages out of
the active list into the inactive list. As it transitions from
active to inactive, the system unmaps it from memory, so that it can
detect a fresh reference. When the system needs to grow the free
pool, it takes the oldest inactive memory.
It's conceivable that you could based your estimated of system memory
pressure on the size of the active/inactive lists. There are a
couple of caveats though:
1. Kernel engineering generally recommends against calling Mach APIs
directly. These APIs are tightly bound to the kernel implementation.
If the implementation changes it's likely that the numbers returned
will be a rough compatibility guestimate. [A terrifying example of
this is thread scheduling parameters.]
2. As with any optimisation, if the underlying implementation
changes, your algorithm may no longer be optimal. For example,
programs that used lots of Handles were highly optimised for a Mac
128, but severely suboptimal on Mac OS X. It's quite possible that
this sort of change will happen again in the future.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden