"David S. Miller" <davem@redhat.com> writes:
> X86_64 on the other hand seems to run x86 binaries in a similar
> fashion. I don't know how people currently doing this port intend
Yes it does.
> to do the useland, but I bet it would benefit from a mostly 32-bit
> userland just like sparc64/ppc64 does, both in space and performance.
Apart from a few unfortunate exceptions[1] the code size growth from
ia32 to x86-64 is very moderate. The binaries appear a bit bigger
because they have an .ehframe linked in by default, but .text growth
is not that bad (normally 5-10%, in some cases it even gets smaller)
Random sample (with .ehframe stripped):
64bit ls:
-rwxr-xr-x 1 root root 76672 Oct 25 05:59 /bin/ls
text data bss dec hex filename
64847 7752 1136 73735 12007 /bin/ls
32bit ls:
-rwxr-xr-x 1 root root 68524 2002-09-09 22:56 /bin/ls
text data bss dec hex filename
65353 1112 872 67337 10709 /bin/ls
[< 1K .text growth, some .data growth due to 64bit pointers]
Performance is good too and gcc is a lot happier with 16 general purpose
integer registers than with 8.
The current x86-64 distributions I'm aware of have a full 64bit userland.
That said you can run a 32bit distribution with a 64bit kernel just fine,
with the exception of modutils, but that should be fixed now with the 2.5
in kernel module loader. Good 32bit emulation is a goal for the port.
So you can run what you want - 32bit or 64bit - but the default is 64bit.
-Andi
[1] emacs is twice as big because its fundamental lisp word grows
from 32bit to 64bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:12 EST