site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jun 1, 2005, at 4:03 PM, Peter Bierman wrote: What do you intend to do with the number when you have it? It is a meaningless number. Tony -pmb _______________________________________________ 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 2:28 PM -0500 5/31/05, Tony Scaminaci wrote: The following calculation of free memory (in bytes) No, it's used to allocate and lock a memory test buffer. That's what the application does, test huge chunks of memory, preferably close to all of the installed ram that the kernel will give up. In single-user mode, the kernel seems willing to give up about 97.2% of what vm_stat reports being available. Some amount larger than the "unused" RAM can usually be used without performance degradation. True, and I have experimented with grabbing some of the inactive memory as well. In Jaguar and Panther, grabbing too much inactive memory would cause the machine to stop responding to user input from the keyboard or mouse. What was going on, I have no idea. Either the OS was paging out huge chunks of application code or the OS just simply stopped responding. With a lot of experimentation, I found the safest thing to do was only lock free ram as reported by vm_stat. I didn't want to risk slowing a user's system down or creating a bunch of page files (which I also saw during my experiments). Some amount larger than the "phsyical" RAM can be usually used with a slight performance impact. This is not useful to my application. Memtest's purpose is to test the DIMMs and CPU caches, not VM. I specifically DON'T want this behavior so I have to take precautions to ensure that the memory I lock using mlock() is ONLY physical RAM. The absolute safe way to do this is to allocate and lock only the free memory reported by vm_stat. I could go slightly over that and cause some apps to page to disk but if I go to far into the inactive space, the machine becomes unusable. At least for the 30 minutes or so I was willing to wait. There are rarely hard values like "there is 45 MB of free RAM." At any given instant in time, what vm_stat returns is accurate and I use it immediately to allocate and lock memory. I don't know how Tiger is behaving with the issue of grabbing inactive memory space in multiuser mode. I haven't had any time to experiment with it yet. This email sent to site_archiver@lists.apple.com