Re: Losing my memory - a caching problem?
Re: Losing my memory - a caching problem?
- Subject: Re: Losing my memory - a caching problem?
- From: Ken Ferry <email@hidden>
- Date: Thu, 19 Aug 2010 19:30:05 -0700
On Wed, Aug 18, 2010 at 9:57 AM, Shawn Erickson <email@hidden> wrote:
> 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...
>
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 (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
>
_______________________________________________
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