Kernel prepatch 2.6.26-rc4 [LWN.net]

Linus has released the 2.6.26-rc4 test kernel. In addition to the usual fixes, there are quite a few driver updates in various areas: DRI, networking, MMC, USB, watchdog, and IDE. There is also a fix for 32-bit x86 users who have "too much memory" in their machines. "So if you had PAE enabled _and_ a recent enough CPU to have NX, but not recent enough to be 64-bit (or you were just perverse and wanted to run a 32-bit kernel despite having a chip that could do 64-bit and enough memory that you _really_ should have used a 64-bit kernel), you'd get various random program failures with SIGSEGV. It ranged from X not starting up to apparently OpenOffice not working if it did." As always, all the gory details can be found in the long-format changelog.

(Log in to post comments)

performance is not perverse

Posted May 27, 2008 16:05 UTC (Tue) by jreiser (subscriber, #11027) [Link]

...(or you were just perverse and wanted to run a 32-bit kernel despite having a chip that could do 64-bit and enough memory that you _really_ should have used a 64-bit kernel)...

There's nothing perverse about getting better performance by booting into i686 mode using PAE on a box with dual-core x86_64 and 6GB of RAM. Despite the added overhead of PAE, the kernel is smaller [including no code for 32-bit emulation], the apps are smaller, some "legacy" apps and drivers do not run (or have more bugs) in 64-bit mode anyway, ...

performance is not a reason to run 32bit kernel

Posted May 27, 2008 16:28 UTC (Tue) by khim (subscriber, #9252) [Link]

32bit kernel with >2GB of RAM incurs serious overhead on kernel. Data is moved around many times more then with 64bit kernel. There are probably exist some workloads where 32bit kernel with 6GB of RAM will be faster then 64bit kernel, but they are very artificial. Now 32bit USERSPACE is perfectly legal to use, but that's different story.

performance is not a reason to run 32bit kernel

Posted May 27, 2008 17:20 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

not to mention the fact that in 32 bit mode you only have 8 registers available, but in 64 bit
mode you have 16 available.

most of the other architectures that have 32 bit and 64 bit options on the same chip have the
same number of registers available in both modes, so on those chips the increased code size
causes a performance hit (unless you need to access more ram), but on AMD64/x86_64 the number
of registers available doubles in 64 bit mode.

Not a big deal

Posted May 27, 2008 20:08 UTC (Tue) by khim (subscriber, #9252) [Link]

Surprisingly enough it's not a big deal for kernel. The whole system will be fast NOT when kernel will be uber-optimized and super-fast, but when kernel will use resources as sparingly as possible. Code in kernel does not perform extra-complex calculations so additional registers are not used much - they are mostly used to shorten prologue/epilogue for functions but then commands are longer on average in 64-bit mode so it's a wash. But memory manipulations are really-really hard to do for >2GB of RAM in 32bit mode: high/low memory, endless manipulations with page tables, etc. THIS affects system more then overhead from 32bit API emulation if this memory is actually used and if it's not used... why is it there?

Not a big deal

Posted May 27, 2008 21:12 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

this does affect the kernel to some degree.

the kernel tries to use registers to pass parameters between functions (avoiding the overhead
of accessing the stack), more registers helps keep this efficiant rather then spilling over to
memory.

if you are accessing ram >4G the overhead of the PAE addressing will easily swamp this, but
even on relativly small memory sizes the fact that there are more registers free can be
noticable.