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

Brocade Wants to Be Red Hat of OpenDaylight

Brocade wants to have the same relationship with OpenDaylight as Red Hat has with Linux. Read more

Rise of Linux – a hacker’s history

The original code of Linux was written for fun, or in Eric Raymond’s phrase, to ‘scratch the itch’ of Linus Torvalds, and later to satisfy the enthusiasm and programming itch of an assortment of hackers and hobbyists who, for the most part, had grown up in the age of the ZX80 and the BBC Micro, Acorns and Apricots, for which the code was often available – and hackable. For those who spent their childhood or adolescence delving into the home computers of the late Seventies and early Eighties, playing with software was a learning experience, and something to be shared. Linux could be said to have grown out of this ethos as much as it grew out of the free software movement, or the early Nineties culture of Usenet where “if you wrote something neat you posted it to Usenet” and the only proviso that came with the software was that “if the software breaks you get to keep both pieces.” Read more

Lollipop unwrapped: Chromium WebView will update via Google Play

Android 5.0, codenamed Lollipop, has introduced a key change to the WebView component, used by app developers to display HTML 5 content within their apps, making new features more readily available. Read more

Being a Sporadic Overview Of Linux Distribution Release Validation Processes

Our glorious Fedora uses Mediawiki to manage both test cases and test results for manual release validation. This is clearly ludicrous, but works much better than it has any right to. ‘Dress rehearsal’ composes of the entire release media set are built and denoted as Test Composes or Release Candidates, which can be treated interchangably as ‘composes’ for our purposes here. Each compose represents a test event. In the ‘TCMS’ a test event is represented as a set of wiki pages; each wiki page can be referred to as a test type. Each wiki page must contain at least one wiki table with the rows representing a concept I refer to as a unique test or a test instance. There may be multiple tables on a page; usually they will be in separate wiki page sections. Read more