site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com That would be cool. <http://developer.apple.com/bugreporter/> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 16:43 -0500 1/6/08, Steve Modica wrote: I imagine that a good chunk of inactive memory is page cache (or buffer cache. Not sure which apple uses). Can't these pages be ditched quickly? Keep in mind that the Mac OS X buffer cache is unified. From the kernel's perspective, there's no difference between the VM cache and the file system cache. So your question, as it's written, makes very little sense. If a page is clean, it can be ditched quickly. If that page is mapped into one or more address spaces, it will have to be removed from those address spaces. But the cost of doing that is small compared to any disk I/O. Similarly, if a page is dirty, it doesn't matter how the page got dirty (that is, via file system I/O or via a memory mapping), it will have to be written to disk (back to a file or, in the case of anonymous memory, to a VM swap file). The cost of writing it will completely drown out the cost of unmapping it from memory. Finally, be aware that on Mac OS X 10.5 we introduced a new, fifth category of memory, speculative memory, used to hold pages that have been read from disk speculatively. While the vm_statistics structure was extended to reflect this (see the speculative_count field), the various tools haven't been updated to display it (including Activity Monitor <rdar://problem/5522515> and vm_stat <rdar://problem/5522568>). These tools currently lump speculative pages in with the free pages. (while I'm at it, I sure wish there was a tool around that would show the size and contents indexed by inode of the buffer cache) This email sent to site_archiver@lists.apple.com