On Sun, Dec 01, 2002 at 11:39:01PM -0800, Richard Henderson wrote:
> On Sun, Dec 01, 2002 at 08:46:40PM -0800, David S. Miller wrote:
> > 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
> > 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.
>
> Except that x86-64 binaries get to use 16 more registers, can use
> pc-relative addressing modes, and have a sane function calling
> convention. So things tend to run a bit faster in 64-bit mode.
Cache locality tends to make a much bigger difference. I've been reported
a performance difference of over 100% for certain applications running 32-bit
on MIPS. 64-bit stuff just tends to push apps out of caches so I don't
see us on MIPS switch to a pure 64-bit any time soon either. Assuming the
availability of 64-bit compiler etc that is - at the moment we're entirely
dependant on the 32-bit environment.
What's the plan to attack 32-bit ioctls? Compared to "normal" syscalls
that's the much bigger dragon. The various ioctl32.c files in the tree
are ugly enough to cause a solar eclipse ;) The only sane solution that
also can work for multiply used ioctl numbers is pushing that down into
the the actual ioctl handlers (as opposed to an implementation sitting on
top of sys_ioctl() which basically is what we're having now) - but I guess
that's going to cause objections?
Ralf
-
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