Re: [PATCH] Start of compat32.h (again)

From: Andi Kleen (ak@suse.de)
Date: Mon Dec 02 2002 - 03:13:58 EST


"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