Re: 64-bit problem with VM statistics
Re: 64-bit problem with VM statistics
- Subject: Re: 64-bit problem with VM statistics
- From: Tony Scaminaci <email@hidden>
- Date: Sat, 4 Jun 2005 13:42:55 -0500
On Jun 1, 2005, at 4:03 PM, Peter Bierman wrote:
At 2:28 PM -0500 5/31/05, Tony Scaminaci wrote:
The following calculation of free memory (in bytes)
What do you intend to do with the number when you have it?
It is a meaningless number.
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.
Tony
-pmb
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden