Re: 64 bits Kernel and 32 bits process
Re: 64 bits Kernel and 32 bits process
- Subject: Re: 64 bits Kernel and 32 bits process
- From: Andrew Gallatin <email@hidden>
- Date: Mon, 17 Jan 2005 13:50:56 -0500 (EST)
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden