Live data from Hacker News

Linux 3.4 kernel released

kernelnewbies.org

41–47 of 47 posts

Re: Linux 3.4 kernel released

#41
post #33
post #3

The X32 ABI is interesting. Who'd have thought this many years after 64 bit becoming mainstream, (and decades after it becoming mainstream on servers) something like this would be needed.

SGI's IRIX always had the ability to do since decades ago. Of course, like others have stated, the main reason is to conserve both memory (for pointers) and more importantly bus bandwidth (which is a mayor problem in MPI/SMP systems memory, especially in those IRIX supported with 128+ cpus in a NUMA configuration). There are still many features where linux is just playing catch-up that commercial unix kernels had dec…

In fairness, x86-64 Linux has supported running 32-bit x86 processes from the start (likewise for PPC and PPC64). It just so happens that the difference between 32-bit and 64-bit CPU modes is quite significant on x86. So this new ABI for using 32 bit pointers while the CPU is in 64-bit mode is really Intel/AMD's "fault" more than Linux's - the 32-bit mode's register starvation is particularly crippling. (Actually, if anyone is to blame, it's Microsoft "fault" for tying consumer computing down to x86)

Re: Linux 3.4 kernel released

#42
post #12
post #6

Earlier quoted context omitted.

Anyone has a good argument why NOT to use this for every non memory intensive application? I always thought that using 64bit pointers was a waste of memory when not needed and this x32 abi to me seems fantastic since it keeps the several advantages of newer 64bit cpus (more registers for example as mentioned in the article).

seems like a great idea. toolchain support may be an issue for a while, especially if you link against libraries with a different ABI. one thing to keep in mind is that the performance gain from e.g. more registers may not be as big as you'd think, since the hardware already plays lots of tricks to get around i386's limitations (e.g. register renaming) and likely extracts a good bit of the available ILP.

Actually main line kernel support is one of the last things that's been needed to get this going. gcc 4.7, and the latest glibc and binutils have had support for a little while. Now it'll still be a while before distros start supporting it as a first class citizen but the pieces are now there.

Re: Linux 3.4 kernel released

#43
post #33
post #3

The X32 ABI is interesting. Who'd have thought this many years after 64 bit becoming mainstream, (and decades after it becoming mainstream on servers) something like this would be needed.

SGI's IRIX always had the ability to do since decades ago. Of course, like others have stated, the main reason is to conserve both memory (for pointers) and more importantly bus bandwidth (which is a mayor problem in MPI/SMP systems memory, especially in those IRIX supported with 128+ cpus in a NUMA configuration). There are still many features where linux is just playing catch-up that commercial unix kernels had dec…

IRIX may have features that Linux lacks but this is not an example of one. Linux supports 32-bit binaries with 32-bit pointers that run on 64-bit kernels on the other 64-bit archs, like powerpc or sparc64.

This problem is really a quirk that results from the fact that AMD made significant changes to the arch(added 16 registers) when they invented amd64.

Re: Linux 3.4 kernel released

#44
post #6
post #3

The X32 ABI is interesting. Who'd have thought this many years after 64 bit becoming mainstream, (and decades after it becoming mainstream on servers) something like this would be needed.

Anyone has a good argument why NOT to use this for every non memory intensive application? I always thought that using 64bit pointers was a waste of memory when not needed and this x32 abi to me seems fantastic since it keeps the several advantages of newer 64bit cpus (more registers for example as mentioned in the article).

Recently there was a HN thread [1] about the conservative garbage collection used in some 32bit VMs (the complaint started with Go), because the way their GC works is by scanning portions of process memory for 32 bit values that map to valid address space for that process. Those values are treated as pointers even if they're not pointers, so the data they point to is assumed to be used and is not garbage collected.

Architectures/ABIs with 64bit pointers have a much lower probability of arbitrary values mapping to active memory space for the process, so memory bloat caused by the conservative GC strategy is much more limited.

The x32 abi looks like it would suffer from this 32bit conservative garbage collection problem too. Short of changing the VM strategy, using 64 bit pointers is the only way to ensure that such VMs do not accumulate so much unused but not-garbage-collectable memory allocations.

[1] http://news.ycombinator.com/item?id=3814020

Re: Linux 3.4 kernel released

#45
post #33
post #3

The X32 ABI is interesting. Who'd have thought this many years after 64 bit becoming mainstream, (and decades after it becoming mainstream on servers) something like this would be needed.

SGI's IRIX always had the ability to do since decades ago. Of course, like others have stated, the main reason is to conserve both memory (for pointers) and more importantly bus bandwidth (which is a mayor problem in MPI/SMP systems memory, especially in those IRIX supported with 128+ cpus in a NUMA configuration). There are still many features where linux is just playing catch-up that commercial unix kernels had dec…

Yes Linux is the new old - IRIX had transparent hugepage support in 1993 Linux had it implemented this year.

Re: Linux 3.4 kernel released

#47

I'm confused. Is 3.x meant for a different class of system, or are distros like Ubuntu intentionally lagging behind in 2.6.x land?

Ubuntu 12.04 runs kernel 3.2.

Ugh, thanks. I forgot I'm still running 11.10. I should've checked around first.
Post reply on HN