Re: 64-bit problem with VM statistics
Re: 64-bit problem with VM statistics
- Subject: Re: 64-bit problem with VM statistics
- From: William Kucharski <email@hidden>
- Date: Sun, 5 Jun 2005 03:19:37 -0600
On Jun 4, 2005, at 12:27 PM, Tony Scaminaci wrote:
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.
PowerPC, as the Mac uses it, is a big endian platform.
Thus say you have a memory buffer at location 0x1000.
If the buffer is to be an unsigned int, the value goes into the four
bytes starting at 0x1000, MSB at 0x1000.
If the buffer is to be an unsigned long long, the value goes into the
eight bytes starting at 0x1000, MSB at 0x1000.
If the kernel thinks it's filling in an unsigned int at location
0x1000, it just writes those first four bytes, which happen to be the
most significant four bytes of an unsigned long long as seen from
that address.
Make sense? e.g.: 0xfeedfacedeadbeefULL is represented in memory as:
0x1000: 0xfe
0x1001: 0xed
0x1002: 0xfa
0x1003: 0xce
0x1004: 0xde
0x1005: 0xad
0x1006: 0xbe
0x1007: 0xbf
0xc0edf00d as an unsigned int would be:
0x1000: 0xc0
0x1001: 0xed
0x1002: 0xf0
0x1003: 0x0d
Why does it print correctly? Assuming you're just doing the printf
with an unsigned specifier, the printf will only read those first
four bytes as the value to be printed, so
the printf will print the value 0x1000, but the system sees the value
as the 64-bit
quantity 0x100000000000ULL.
This would defeat the purpose of running a 64-bit executable - to
test more than 4 GB of memory. The memory address pointers have to
be 64 bits if they're going to be able to access all the memory a
user has installed.
You're confusing virtual and physical addresses here; as long as the
operating system can access physical memory with 64-bit addresses, a
user could use a 32-bit address to access that memory, though not
more than 4G at a time. Think of it as a sliding 32-bit window
accessing the full 64-bit memory space.
But in general, you want to use the 64-bit interfaces, which leads to:
This is definitely an option if the 64-bit compiler will allow it.
Even worse, I could just set the page size to 4096 and be done with
it. Not a good idea in case it ever changes but it seems to be 4K
on most modern OS's these days.
There is "nothing wrong" with passing host_page_size the address of a
32-bit variable as long
as the kernel isn't compiled with __ppc64__ set and as such won't try
and write a 64-bit
quantity to the 32-bit variable's address.
As I said, this is somewhat of a hole in the current implementations,
and Apple DTS should really be the ones to resolve it one way or the
other.
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?
See above; you're not grasping the concept of a 32-bit virtual
address addressing memory via a 64-bit physical address. This is how
the kernel dealt with memory pre-Tiger; apps could
access memory mapped with a 64-bit physical address space, an app
just couldn't access more than 4GB at a time.
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.
32-bit applications CAN 'use' more than 4GB of memory at a time, but
not via the standard malloc() interfaces in continuous virtually
mapped buffers more than 4GB at a time.
If you think this is fun, PCI devices can only address a 32-bit
memory space, so when using PCI devices on a 64-bit architecture,
memory address translation must be done if you want to allow those
devices to access the entire memory space. This is what the DART is
all about, as described here:
<http://developer.apple.com/documentation/Darwin/Conceptual/
KernelProgramming/vm/chapter_7_section_8.html>
So, bottom line, you're correct in wanting to compile your app in 64-
bit mode, but there's a hole in this particular call that causes
things to break due to Darwin's current mixed 32/64-bit nature.
If Apple would move to a full 64-bit kernel, like Solaris or, as of
2.6, Linux, a lot of these issues would go away at the cost of
compatibility with existing device drivers and some kernel code bloat
as opcodes got wider. In theory IOKit should insulate even the
driver level from the implementation details of the kernel itself,
but in practice it's a lot more complex and MacOS X remains astraddle
the 32/64-bit line...
William Kucharski
email@hidden
_______________________________________________
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