Michelasso wrote:
It is labeled as "swap used", as you know already. That is the total amount of memory actually stored inside the /private/var/vm swap file(s).
That is not exactly true. AM's "swaps used" shows the amount of information actually swapped out to the hard drive. See for example this KBase article for a simplified explanation of how to interpret AM's memory info.) The swapfile(s) in private/var/vm/ are created with fixed sizes. It is important to understand that these swap files are organized into pages of 4 KB each, & each page may be swapped in & out individually.
So for example, you might have just one swapfile0 in private/var/vm/ with only some of its pages actually ever used to store anything, with some pages used over & over again when their previous contents are no longer needed. Or you might have also have a swapfile1, created when swapfile0 wasn't big enough to hold all the pages that needed to be swapped out, but at some later time its pages also might be only partially used, or not used at all.
It might help to think of the swapfiles' size(s) as something like a measure of the capacity of the box(es) used to store swaps & "swaps used" as a running total of what was put into them. Obviously, if you take something out of the box you can put something else in its place.
Where your description of virtual memory fails in Lion is that sometimes Lion simply does not release the active memory.
Lion should never release active memory. Memory pages must first be moved to the inactive list before they can be paged out. Did you mean to say inactive memory instead? If not, refer to the Paging Out Process section of the developer doc for an explanation of the steps in the process.
As you already know, before to start the resource's expensive job of paging out, the pager should first release the inactive read memory.
I'm not sure what you mean "read memory." It doesn't matter if the page holds code, data, or whatever. If it has to be paged out, it takes resources to do that.
What wouldn't make sense is why such large amounts of memory, mostly junk, have been marked for retention and not released already.
What makes you think that the retained pages contain mostly junk? If say Safari has caused some code to be initialized in RAM that hooks into a system API (say to run a movie), it would not make sense to release it as long as Safari is running unless that RAM is needed to run something else.
Logic says that since only the inactive memory can be paged out (it's one reason why it's there after all) and since in my case it is always less than 1GB I shouldn't have more than 1GB of data paged out.
I don't follow your logic. As mentioned above, many more pages can be swapped out than the total of what can fit into all the available RAM at any one time. That's the point of using VM.
Last thing: you say that it is ok for Safari to retain the memory used by all pages.
That's not what I'm saying. I'm saying that the contents of some of the pages retained in RAM are likely to be reused, so they are not discarded unless & until that is necessary.
It may help at this point to refer to the "Paging In Process" section of the developer doc. Note that page ins can occur from either the backing store (the swapfiles) or from ordinary files. But even if some pages are not currently mapped into the app's virtual memory space, they still may be resident in physical memory because they were previously used & not yet released. In that case, a soft fault occurs & the pages just need to be marked as active again. But if they are not in physical memory a hard fault occurs & they must be paged in, from either the backing store via the default pager or from the file on disk via the vnode pager. In either case, if the page is involved in a write operation, the page is marked as modified & must be written to disk to preserve the newly written info before the page can be freed up for other processes. If it is never modified while it is in physical memory (not written to), it may be released without having to be written back to disk. Obviously, if the system has to write a page out before it can read another one in from the disk, the performance impact is much worse than if it just has to read the page.
But also note that different processes or even different sections of code within one process can share pages, as explained in the third paragraph of the Details of the Virtual Memory System section of the doc. As long as no process writes to those pages, they do not have to be written back to disk either.
I hope all this helps explain why understanding why the VM system retains some things in RAM longer than seems necessary or desirable can be a formidable challenge, even with the system-wide statistics Activity Monitor, vm_stat, or similar tools provide. They just do not provide the detailed, process-by-process info necessary to do this, for instance what the contents of some specific page holds, which (if any) processes may have modified it, or what occurs between sample intervals -- which can be a great many things per second, especially for soft faults that never have to write anything back to disk.
