On Wed, Aug 18, 2010 at 9:57 AM, Shawn Erickson <shaw...@gmail.com> wrote:
> 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... > FYI, I'm not up on the details, but the precise definitions of inactive, active, and free changed for… I think 10.5. Possibly 10.6 as well. So, (a) Singh's book is probably not precisely accurate to the new definitions, (b) the numbers are not comparable across major OS revisions. -Ken Cocoa Frameworks > > 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/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > _______________________________________________ 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
