Hi Rick, > > Please note, that we will not remove the 31 bit compatibility layer which > > allows to run 31 bit applications with a 64 bit kernel. It is also > > possible to run a complete 31 bit user space distribution with a 64 bit > > kernel. > > Good. > > Question: If you're dropping 31-bit in the kernel, what's the rationale > for retaining 31-bit in the run-time? (That is, what is IBM's business > case for retaining the 31-bit run-time?)
The reasons are - There are indeed old 31 bit applications that we want to support. - Speed. As you already wrote 31 bit applications are faster. > As implied, I'd really like to know where the 31-bit speed-up happens. > If it's just the run-time, then I for one will make no complaints (about > taking the kernel 64-bit only). That should come from the applications, since, e.g. the stack frames are smaller etc.. Please note that the fastest executing applications should be those that you compile with '-m31 -mzarch -march=<yourmachine> -O<yourchoice>' if you use gcc. So if you have a 64 bit kernel (with highgprs support), user space applications can be compiled for the 31 bit ABI but still are allowed to use 64 bit registers and instructions only available in z/Arch mode. This option should give you the fastest execution times of 31 bit applications. Even faster than with a 31 bit kernel, since if you have a 31 bit kernel everything runs in ESA/390 mode and you can't use the 64 bit registers and z/Arch instructions there. Another advantage of having a 64 bit kernel and 31 bit user space is that your virtual machine is not limited to 2GB of storage anymore. While each 31 bit application obviously still is limited to its 2GB address space, the kernel can make use of much more physical storage; which could be a relief if your 31 bit workload needs a lot of memory and the kernel starts swapping due to the 2GB limit. > > After the removal of the 31 bit kernel support it is not possible to run > > new Linux kernels on old 31 bit only machines. The only supported 31 bit > > only machines were the G6 and Multiprise 3000 introduced in 1999. However > > after nearly 15 years it seems reasonable to remove support for these old > > machines. > > And that's the real question. For other primary architectures (eg: I386 > versus X86_64) there is a planet full of existing hardware. AMD and > INTEL don't have the vice-grip control over those deployments that IBM > enjoys with S390/S390X. Well, it's not that for the x86 architecture support for old hardware doesn't get removed. E.g. support for 80386 CPUs has been removed a year ago as well for the same reason (removing complexity from a developer's perspective): http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=743aa456c1834f76982af44e8b71d1a0b2a82e21 Thanks, Heiko ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
