[kde-linux] Very ugly image in X root window.

[Duncan]

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