Re: 64-bit problem with VM statistics
Re: 64-bit problem with VM statistics
- Subject: Re: 64-bit problem with VM statistics
- From: Jim Magee <email@hidden>
- Date: Wed, 8 Jun 2005 06:38:04 -0700
Sorry for the delay...
On Jun 4, 2005, at 11:27 AM, Tony Scaminaci wrote:
On Jun 2, 2005, at 1:43 AM, William Kucharski wrote:
I found your problem, and it's an interesting one.
The problem lies here in your code and the fact that you have your
project set to be compiled in 64-bit mode for G5s:
vm_size_t mac_pagesize;
[ ... ]
host_page_size(host_port, &mac_pagesize);
...
What this means is if __ppc__ is defined, vm_size_t will be an
unsigned int (size 4 bytes); if __ppc64__ is defined, vm_size_t
will be a unintptr_t (size 4 bytes on PPC32, 8 bytes on PPC64.)
The problem is that the kernel is NOT a 64-bit executable, and as
such is not compiled with __ppc64__ set, so when you make this
call from a 64-bit executable:
host_page_size(host_port, &mac_pagesize);
the Darwin kernel does this:
kern_return_t
host_page_size(
host_t host,
vm_size_t *out_page_size)
{
if (host == HOST_NULL)
return(KERN_INVALID_ARGUMENT);
*out_page_size = PAGE_SIZE;
return(KERN_SUCCESS);
}
I think you probably see the issue here;
Yep, this is a bug with host_page_size(). Since it is a message to
the Mach kernel, it doesn't have the information about what kind of
address space the caller has, and therefore can only fill in the
legacy size. The usual approach we took in these situations was to
add a second RPC for 64-bit clients (and then aliased the name in the
build of the 64-bit Libc). But this one slipped through the cracks.
Why wouldn't it fill in the lower four bytes instead? I ask this
because when I print out mac_pagesize, I do get 4096 as expected so
the lower bytes must have the correct value.
As someone else explained, the printf directive you used triggers the
same "looking at the wrong bytes" issue as the host_page_size results
output did. If you look in the debugger (on big-endian PowerPC),
you'll see the big number.
The question is, what SHOULD happen in this case, and should there
be an ADC tech note warning of this issue?
According to the Darwin 64-bit conversion guide (<http://
developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/
index.html>), "Only libSystem and the Accelerate framework are
available to 64-bit developers. Higher level frameworks are 32-bit
only." But is a call to host_page_size() really considered a
"higher level framework?"
I'd consider host_page_size() to be part of libSystem if anything.
If we can't address more than 4 GB of memory, what's the point of
having a 64-bit OS and a PPC G5? At the very least, Tiger should be
able to get at all of the user's installed memory assuming the user
runs a 64-bit app. How can the kernel handle more than 4 GB of
address space if it's not 64-bit?
The host_page_size() returning the wrong thing in 64-bit land doesn't
make it so you "can't address more than 4GB of memory." Yep, it's a
bug. How could this slip through? Because Libc, through mach_init
(), provides a global "vm_page_size" for this value. It is
initialized differently for 64-bit processes (as you guessed it -
hard coded for now). The intent was to move to use of a value in the
commpage (memory shared between the kernel and user-space containing
such configuration values). That value would be used to initialize
both the global and the return value for host_page_size(). We didn't
quite get there - and you see the results.
There's got to be a simple workaround to this problem. I can't be
the only person trying to use more than 4GB of memory at one time.
Any application that bills itself as 64-bit has to address these
issues.
So, my suggestion is to use the Libc-provided vm_page_size global
instead of calling host_page_size() yourself. Heck it's even more
efficient. And you don't have to worry about releasing the host port
reference returned from mach_host_self() (which hardly anyone does
correctly).
--Jim
_______________________________________________
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