Language Selection

English French German Italian Portuguese Spanish

Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks

Filed under
Ubuntu

Coming up in our forums was a testing request to compare the performance of Linux between using 32-bit, 32-bit PAE, and 64-bit kernels. This is coming after Linus Torvalds has spoke of 25% performance differences between kernels using CONFIG_HIGHMEM4G and those without this option that allows 32-bit builds to address up to 4GB of physical RAM on a system. We decided to compare the performance of the 32-bit, 32-bit PAE, and 64-bit kernels on a modern desktop system and here are the results.

For this comparison we used Ubuntu 9.10 on a Lenovo ThinkPad T61 notebook running an Intel Core 2 Duo T9300 processor, 4GB of system memory, a 100GB Hitachi HTS7220 SATA HDD, and a NVIDIA Quadro NVS 140M. We were using the Ubuntu-supplied kernels that are based off the Linux 2.6.31 kernel in Ubuntu Karmic. Other packages that were maintained included GNOME 2.28.1, X Server 1.6.4, NVIDIA 195.22 display driver, GCC 4.4.1, and we were using the default EXT4 file-system with all other defaults. With Ubuntu to properly address 4GB or greater of system memory you need to use a PAE kernel as the Physical Address Extension support through the kernel's high-mem configuration options are not enabled in the default 32-bit kernels. CONFIG_HIGHMEM4G is enabled in the default Ubuntu kernel, but the Ubuntu PAE kernel uses CONFIG_HIGHMEM64G (and other build options) for handling up to 64GB of system memory. Of course, with 64-bit addressing there is not this greater than 4GB RAM limitation. Though even with a 32-bit non-PAE kernel the system will only report 3GB of system memory by default due to 1GB of that being reserved for kernel virtual addresses while the 3GB is available to user-space addresses.

rest here




More in Tux Machines

Games for GNU/Linux

Containers News

  • Docker 1.13.0 Just Around the Corner as Docker 1.12.4 Enters Development
    Victor Vieux from the open source Docker app container engine released new development versions of the upcoming Docker 1.13.0 major milestone and Docker 1.12.4 maintenance update for the current stable series. The third Release Candidate (RC) version of Docker 1.13.0 arrived a couple of days ago with numerous minor tweaks and fixes to polish the software before it's tagged as ready for production and hits the streets, which should happen in the coming weeks. Docker 1.13.0 RC3 comes two after the release of the second RC build.
  • Pet Containers: You’re Not Doing it Wrong
    The conventional wisdom of Linux containers is that each service should run in its own container. Containers should be stateless and have short lifecycles. You should build a container once, and replace it when you need to update its contents rather than updating it interactively. Most importantly, your containers should be disposable and pets are decidedly not disposable. Thus the conventional wisdom is if your containers are pets, you’re doing it wrong. I’m here to gently disagree with that, and say that you should feel free to put your pets in containers if it works for you.

AMDGPU News

  • Vulkan/OpenGL Performance With AMDGPU-PRO 16.50 vs. Mesa 13.1-dev
    This morning's AMDGPU-PRO 16.50 preview included some 16.40 vs. 16.50 hybrid driver benchmarks, but for those wondering how 16.50 compares to Mesa 13.1-dev for RadeonSI OpenGL and RADV Vulkan, here are some preliminary tests for the two current Vulkan AAA Linux games.
  • Here Is The AMDGPU-PRO 16.50 Download Link
    AMD ran into a snag getting out the updated proprietary hybrid Linux driver stack this morning, but it's now available for download from AMD. This page has the 16.50 Linux x86/x86_64 driver available for download.
  • It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel
    While AMD developers have been working to improve their "DAL" (now known as "DC") display code for the better part of the past year and this code is needed for new hardware support as well as supporting HDMI/DP audio on existing AMDGPU-enabled hardware plus other features, it's still not going to be accepted to the mainline kernel in its current form.

Linux Foundation and Linux