James Tyrer posted on Sat, 12 Nov 2011 19:24:48 -0700 as excerpted: > But, I probably won't have to worry about it any more since I just > installed 4 GiB of RAM. System does run much faster.
=:^) > You can't use all of it with 32 bits -- KInfoCenter says it sees > 3.22 GiBs. I haven't decided whether to do 64 bit. I will have > to read up on it. First question is whether I can have only the OS > as 64 bit. Only the OS? Which bit do you consider the OS? Do you mean only the kernel, not userspace? I've just never heard someone say they want only the OS as 64-bit before, and it struck me as definitely odd and funny sounding, because on Linux where most of the apps are supplied by the distro, there really is no clear dividing line between OS and non-OS. The clearest dividing line is kernel/userspace. Most folks with any knowledge would probably include the libc (normally glibc but occasionally a different alternative), a more or less POSIX compliant shell (normally bash), the init system (traditionally a sysv style init, but now days systemd is popular), probably udev, likely grep/ sed/head/etc, as often used in the initscripts, etc. Some would include xorg and presumably a default desktop environment, tho others wouldn't. But... there's really no clear dividing line in all that, only the one between kernelspace and userspace, and really no easy place to divide between 32-bit and 64-bit, except between userspace and kernelspace, so seeing discussion of only the OS being 64-bit appears odd indeed, to anyone who has even sideways-glanced at the situation. Meanwhile, do I recall correctly that you run LFS, and compile everything from sources yourself? If so: 1) What you said about 32-bit isn't entirely correct. The 32-bit x86 Linux kernel has a number of different configuration options in regard to memory. First, there are the so-called "normal" modes, which split 4 GiB of address space between the kernel and the apps. IDR which is considered normal-normal since I've been on 64-bit amd64 (x86_64) since I had enough memory to matter, but the split can be 2:2, 1:3 or 3:1 user/kernel. These modes do indeed allow access to only ~3-3.5 gigs, due to the 32-bit PCI-hardware I/O region at the top of the 4-gig memory address space. Note that this hardware I/O region is taken from the address space assigned to the kernel, so if split it 3 gig user, 1 gig kernel, that forces the operating kernel into, in your case, about a quarter-gig of address space, which isn't a lot for address randomization, etc. That's rather tight. Meanwhile, the user-space size determines how large an individual application may be. If you allow only a gig for userspace, apps can only grow to a gig in size, then they crash. But a gig is enough for most non- database type apps. (FWIW, as one not normally considered database example, pan, the news client, can use multiple gigs on large binary groups on servers with long retention such as giganews. Unfortunately it retains the entire message tree in memory. =:^(.) Second, there's a 4:4 mode, where the kernel and userspace each get their own 4 GiB address space to work with. This allows apps of 3 GiB plus (probably the 3.22 GiB reported for your case) and gives the kernel plenty of space to work in as well, *BUT* there's an efficiency tradeoff in that every time the system switches between user-mode and kernel-mode it must flush the TLBs (translation look-aside buffers) and do other bits of housekeeping that can cut performance by several percentage points, depending on the given task load. Thus, this mode is occasionally considered usable for (again, particularly database) servers, but not generally for desktop usage. YMMV. Third, there's PAE (Physical Address Extension, see wikipedia but any hardware that can physically handle the memory should have it) mode, allowing access to upto 64 GB of RAM using a 4-gig window, so 4 gigs at a time. PAE mode has efficiency issues as well, but it DOES allow a 32-bit x86 Linux kernel to access and use to upto 64 GiB of physical memory. One bonus of this mode is that it also enables the NX (no-execute memory mapping) bit, allowing for better security if enabled. As a result, I believe some distros ship a PAE-mode kernel as the default, at least for the server product, where SELinux or the like may also be enabled by default. So it's not exactly correct to say that 32-bit x86 Linux won't let you access >= 4 GiB of RAM. The upper limit is actually 64 GiB altho there's tradeoffs. As a result, going with a 64-bit kernel is clearly a better alternative, where possible. 2) Yes, it's very possible to run kernel-only-64-bit, with a 32-bit-only userspace. On architectures other than x86, that's actually the most common 64-bit mode, but due to various limitations embedded in 32-bit x86, particularly the extreme shortage of usable registers, a full 64-bit system, or 64-bit but for a few 32-bit apps (typically due to lack of sources, 32-bit binary-only non-freedomware) and associated libraries, commonly called a multilib setup, is more common on x86 than the otherwise more common 64-bit kernel, 32-bit userspace arrangement. Actually, perhaps it was multilib that you were referring to with 64-bit OS only. But it's not called that, because as I explained, there's no clear dividing line except for that between kernel and userspace. Instead, it's called multilib, because the common system libraries are installed in both 32-bit and 64-bit forms, and binaries using either set can be run. The drawback of multilib, however, is that it's way more complex, meaning there's more that can go wrong, and for those building from sources, as I do here on Gentoo and as LFS folks do with even less automation, many libraries and a few executables are often built twice, once each for 32- bit and 64-bit. It is for this reason, plus the fact that I'm freedomare only so didn't need 32-bit-binary-only-compatibility, that I ultimately switched away from the normal gentoo/amd64 multilib profiles to a no- multilib profile, eliminating a whole class of problems and significantly decreasing my build time for a number of packages that were built twice on multilib, once for 64-bit, once for 32-bit. (Actually, at one point a four-time build was common for glibc, as it was built once each for NPTL and for Linux threads, for each of 32-bit and 64-bit, but the old Linux threads isn't used so much any more, so I believe NPTL-only is common today.) Another alternative, since amd64/x86_64 can run both 32-bit and 64-bit code as long as you have the kernel option enabled to do so, would be to do a self-built 64-bit-only install, then in a chroot, do a 32-bit-only install, either self-built as well, or as a typical binary distro installation. Here on Gentoo/amd64, that's called the 32-bit chroot option. The main system is 64-bit, but you can run anything you want from the 32-bit chroot as well. 3) There's actually a new Linux "arch" just coming out now, called x32. Some details are still being hashed out and it's likely it'll never be fully mainstream, but the idea is to have a 64-bit kernel, and 32-bit userspace, but with a twist! As I touched on earlier, traditional 32-bit x86 has some serious hardware limitations. As a result, full 64-bit systems and 64-bit-default multilib setups are far more common on x86 than they are on most other Linux archs. But, while most apps DO benefit from removing the limitations of 32-bit x86, on the desktop at least, most apps still function fine, if a bit less efficiently on x86, in 32-bit mode, as few apps actually use more than a couple gig of memory, and SSE and similar x86 instruction set extensions already provide much of the functionality that would otherwise require 64- or even 128-bit. This new x32 mode/arch uses a 64-bit kernel but only a 32-bit user-side address space. Where necessary to take advantage of the efficiencies of 64-bit mode, normally 32-bit user-side addresses are padded to 64-bits, and the "native" system/kernel function calls are defined such that the most efficient one, 32-bit or 64-bit, or a special mixed-mode call where necessary, are used. Because x32 is so new, the patches for it are only merged to kernel mainline for 3.2 I believe, and I'm not sure they made it for that, it might be 3.3, and the glibc functions are still being hashed out as well, this arch won't be ready for "ordinary mortals" to use until mid-year next year (2012) at the earliest. Also, it's an open question how many distros will offer it. But there's already a gentoo project for it and one of main guys (Mike Frysinger, aka vapier, if you follow the mainline Linux kernel he is I believe the lead for the sh arch there, already) on the upstream project is also a Gentoo toolchain project lead, so Gentoo's pretty much all-in for the project, already. Thus, unless the whole project crashes and burns for some reason, it'll be available on Gentoo at least, probably fairly early. (Actually, it sort of is already, but you'd have to be working pretty closely with vapier in ordered to do anything with it, and it's certainly nowhere near production ready yet, for sure.) FWIW, here's the wikipedia stub for x32 ABI, but there's not a whole lot there yet. http://en.wikipedia.org/wiki/X32_ABI And I might as well throw in this wikipedia entry on PAE as well, since I already have it open. http://en.wikipedia.org/wiki/Physical_Address_Extension -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
