site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Justin Walker writes:

On Jan 17, 2005, at 7:40, Stéphane Sudre wrote:

...

Is there a documentation explaining somewhere very clearly how a 32 bits process is running in a 64 bits capable OS?

Because I'm wondering what kind of address is ok for copyin when the address-space in the kernel is 64 bits.

I have some problem understanding how providing my user space address from a 32 bits process is going to work in every case when the address space can be 64 bits. Unless 32 bits processes can't be executed in the last 32 bits of the 64 bits address space.

Maybe it will help to realize that, for copyin/copyout, there is always magic around to handle the mapping between address spaces. This mapping makes sure that the address/address-space pairs are properly translated so that the result is a "move a byte from here to there" instruction that the computer can execute.

</rant on> This mapping magic is really only required because of the 4GB kernel address space and increases the cost of copy{in,out} tremendously for small copies. This, in turn, increases the cost of every system call. I think I remember something like a factor of 6x or 8x difference between linux ppc64 (genuine 64-bit kernel) and MacOSX (32-bit kernel) on 64-bit G5 hardware the last time I measured our driver's ioctl timings. (linux being faster, of course). In more traditional 1G/3G split 32-bit or pure 64-bit kernel schemes, user virtual addresses are directly accessible in kernel mode, and copy{in,out} is implemented as bcopy plus a fault handler for user virtual addresses which could have been paged out. This is much, much faster than remapping addresses. This performance cost is the main reason that I'm so disappointed that the kernel will remain 32-bits. Then there is the fact that a lot of our driver code assumes a kernel uintptr_t / void * is large enough to hold a user pointer which causes a lot more porting problems for us than a pure 64-bit kernel would have. But then again, we already run in a pure 64-bit kernel Solaris, Linux, Tru64, FreeBSD, so pure 64-bits (with support for legacy 32-bit apps) is no big deal for us. Sorry for tilting at windmills.. </rant off> Drew _______________________________________________ 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... This email sent to site_archiver@lists.apple.com