On Wed, Aug 18, 2010 at 3:45 AM, Stuart Rogers <stuart.rog...@me.com> wrote: > On 18 Aug 2010, at 01:31, Ken Thomases wrote: >> On Aug 17, 2010, at 7:26 PM, Shawn Erickson wrote: >> >>> When you say "free" I assume you mean the "free:" number listed in >>> activity viewer for the system as a whole? >> >>> If so then what you are seeing is an expected result of the "unified >>> buffer cache" maintained by the system (since you say private memory >>> of your application doesn't increase). In a nut shell unused RAM is >>> wasted RAM so the system always attempts to cache once used pages of >>> memory (for example file data loaded by your application) as long as >>> possible until they need to be reused for active / new allocations. >> >> In an even smaller nutshell: you should consider Inactive as equivalent to >> Free in Activity Monitor's System Memory tab. > > I quite understand this, but the practice doesn't quite fit the theory. > If 'inactive' is effectively available as 'free' for all apps, then it should > be > available to my app. And yet, when 'free' drops to just a few megabytes > I see extra swap files being created despite there being several gigabytes > available as 'inactive', which suggests to me that the unified buffer caching > is too aggressive - the cache is being maintained at the expense of swap > files. > > Now, one or two swap files on this machine (an i7 iMac) isn't the end > of the world - I don't really notice any system sluggishness until I get > more than three swap files. But as the target for this software will likely > be a low end Mac, this is a concern - on my 2GB Core Duo MBP this > code will kick off so many swap files the machine becomes barely useable.
To paraphrase Amit Singh's Mac OS X Internals book... free queue - list of free pages that contain no useful data, the VM system pulls new page allocations from this queue first inactive queue - fifo list of pages that are not referenced in a physical map (pmap, aka MMU level mapping) yet they have a valid VM object, these pages contain data and the page can be dirty (aka needs to be written to its backing store on eviction from physical memory). If the free queue is depleted the pager will evicts pages from the inactive queue (writing out the dirty ones to their backing store as needed). active queue - fifo list with lru like insertion ordering of pages that have at least one pmap reference (aka In general pages move from the front of the active queue (oldest page) to the inactive queue, followed by moving from the front of inactive queue to the free queue all based on VM configured thresholds and pressure on the memory subsystem. Pages that get re-referenced can be quickly moved from the inactive queue to the active queue without incurring IO. Dirty pages evicted from the inactive list have to be paged out to their respective backing store (either a page file or back into the memory mapped file). -Shawn _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
