• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: API to get installed RAM
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >API to get installed RAM (From: Tom Bayley <email@hidden>)
 >Re: API to get installed RAM (From: Quinn <email@hidden>)
 >Re: API to get installed RAM (From: "Andy Cave" <email@hidden>)
 >Re: API to get installed RAM (From: Quinn <email@hidden>)
 >Re: API to get installed RAM (From: "Andy Cave" <email@hidden>)

  • Prev by Date: Re: API to get installed RAM
  • Next by Date: MoreSCF - updated version?
  • Previous by thread: Re: API to get installed RAM
  • Next by thread: Re: API to get installed RAM
  • Index(es):
    • Date
    • Thread