Re: Losing my memory - a caching problem?
Re: Losing my memory - a caching problem?
- Subject: Re: Losing my memory - a caching problem?
- From: Shawn Erickson <email@hidden>
- Date: Wed, 18 Aug 2010 09:57:57 -0700
On Wed, Aug 18, 2010 at 3:45 AM, Stuart Rogers <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden