Re: AMD64: 64 bit kernel 32 bit userland - some pending questions

["Albert Cahalan" <acahalan@gmail.com>]

Thomas Glanzmann writes:

> I would like to use an AMD64 Opteron System with a 64 bit Linux Kernel,
> but a 32 bit userland (Debian Sarge). I have a few questions about this:
>
> - Is it possible to give the userland 3Gbyte virtual address
>   space (default for 2.4 and 2.6). But give the Kernel a 64 bit
>   virtual address space so that I get more than 1 Gbyte physical
>   Memory into LOWMEM - say I want 8 Gbyte - without using HIGHMEM
>   at all? If this scenario is possible I would get cheap memory
>   access at the benefit of a well tested userland. I don't have
>   applications that need more than 2 Gbyte virtual address
>   space.

Why do you want cheap memory access? Normally people want this
for performance, but 32-bit apps are noticably slower.

The "well tested userland" is only well tested on a 32-bit kernel.
There are many ways in which a 64-bit kernel fails to correctly
run 32-bit apps. I just found one the other day, in the way signal
handler info gets translated from 64-bit to 32-bit. Some of your
userspace would be something I wrote, which I happen to know will
not run 100% correctly and I just don't care to "fix" it for your
wildly abnormal configuration.

I suspect you have a Windows mindset. In the Windows world, almost
nothing is 64-bit clean. Nearly every Linux app is well-tested in
64-bit form. This is because Linux was ported to the Alpha CPU
back around 1994, give or take a year. That's over a decade of
64-bit experience. It's mainly the proprietary apps that don't
run in 64-bit mode. The one big exception is OpenOffice, which
was also proprietary until Sun opened it up.

Just forget the old 32-bit crud if at all possible. Hopefully
you won't have even one 32-bit library or executable. Make it
your goal to eliminate this buggy cruft. You can use chroot()
or VMWare as needed, but cleaning house is so much nicer.

> - If the above scenario works out like I imagine it, does this
>   add some additional overhead I am not aware of when I switch
>   for example from 32 bit userland to 64 bit kernel space which
>   would override the performance gain I get from the huge LOWMEM
>   virtuall address space?

Of course there is overhead. There are also bugs, some of which
won't ever get fixed.

The bigger problem is that 32-bit code has fewer CPU registers.
(nobody has done an ILP32 ABI for long mode) This is slow.