Speeding Up The Linux Kernel With Transparent Hugepage Support

Last month we reported on the 200 line Linux kernel patch that does wonders for improving the desktop responsiveness of the system. There was certainly much interest (over 100,000 views to both of our YouTube videos demonstrating the change) but this patch really didn't speed up the system per se but rather improved the desktop interactivity and reduced latency by creating task-groups per TTY so that the processes had more equal access to the CPU. There is though an entirely different patch-set now beginning to generate interest among early adopters that does improve the kernel performance itself in compute and memory intensive applications and it's the Transparent Hugepage Support patch-set. Here are our initial tests of the latest kernel patches that will hopefully be finding their way into the mainline Linux kernel soon.

As was pointed out in our forums, the Transparent Hugepage Support patch-set has been updated against the Linux 2.6.37 kernel code-base and is showing to improve the performance in compute/memory intensive applications by a couple percent at this time. The Transparent Hugepage Support in the Linux kernel works by reducing the number of TLB (Translation Lookaside Buffer) entries that such applications need and at the same time increasing the cap that a TLB cache can provide. Transparent Hugepages though have been in the works for sometime now in the Linux kernel and for those interested in a more technical explanation of this support can find a write-up from last year at LWN.net. There is also its kernel documentation.

The latest Transparent Hugepage Support patch that applies the Linux 2.6.37 kernel is just under 7,200 lines. Besides applying the patch, the kernel needs to be built with the new CONFIG_TRANSPARENT_HUGEPAGE option. The Transparent Hugepage support can then be toggled in the newly built kernel at boot-time with thetransparent_hugepage option or via its sysfs interface /sys/kernel/mm/transparent_hugepage/enabled. The support can be enabled, disabled, or with the madvise option for controlling khugepaged. The khugepaged defrag support can also be controlled via its sysfs node (/sys/kernel/mm/transparent_hugepage/khugepaged/defrag) as well as how many pages to scan at each pass, how many milliseconds to wait between each pass, and how many milliseconds to wait in khugepaged if there is an allocation failure to throttle. For our simple purposes we just tested this Linux kernel support with it at its defaults and then when disabled. This was done on a Linux 2.6.37-rc4 kernel and we tossed in Canonical's stock Ubuntu 10.10 kernel based upon Linux 2.6.35 for additional reference.

Worth noting is that user-land applications can also be optimized for Transparent Hugepage Support as a step for taking greater advantage of the larger TLBs. There are some GCC patches floating around for such optimizations, but in our testing, we have just used the stock Ubuntu 10.10 user-land.

Transparent Hugepage Support maximizes the usefulness of free memory if compared to the reservation approach of hugetlbfs by allowing all unused memory to be used as cache or other movable (or even unmovable entities). It does not require reservation to prevent hugepage allocation failures to be noticeable from user-land. It allows paging and all other advanced VM features to be available on the hugepages. It requires no modifications for applications to take advantage of it.

Applications however can be further optimized to take advantage of this feature, like for example they've been optimized before to avoid a flood of mmap system calls for every malloc(4k). Optimizing userland is by far not mandatory and khugepaged already can take care of long lived page allocations even for hugepage unaware applications that deals with large amounts of memory.

In certain cases when hugepages are enabled system wide, application may end up allocating more memory resources. An application may mmap a large region but only touch 1 byte of it, in that case a 2M page might be allocated instead of a 4k page for no good. This is why it's possible to disable hugepages system-wide and to only have them inside MADV_HUGEPAGE madvise regions.

Embedded systems should enable hugepages only inside madvise regions to eliminate any risk of wasting any precious byte of memory and to only run faster.

Applications that gets a lot of benefit from hugepages and that don't risk to lose memory by using hugepages, should use madvise(MADV_HUGEPAGE) on their critical mmapped regions.

Our basic testing of this feature was done with a Lenovo ThinkPad T61 notebook boasting an Intel Core 2 Duo T9300 "Penryn" CPU with 4GB of system memory, a 100GB Hitachi 7200RPM SATA HDD, and NVIDIA Quadro NVS 140M graphics. It was running Ubuntu 10.10 with GNOME 2.32.0, X.Org Server 1.9.0, NVIDIA 260.19.21 binary driver, GCC 4.4.5, and an EXT4 file-system.

Transparent Hugepages will not speed-up all Linux applications, but with memory and/or CPU intensive applications, it will cause some performance boosts, even without any user-land modifications. From the handful of Phoronix Test Suite benchmarks run, the best example we found was with NASA's OpenMP-based Fortran-written NAS Parallel Benchmarks. In particular, with the IS.C test, the performance jumped by more than 20%.

This though is an outlier with basic pieces of software (games, simple encoding tests, etc) not changing much and in other areas the gains were within a couple of percent.

It will be much more interesting though to see the performance once a number of Linux applications have been tuned to take advantage of this support and when the support is mainlined in the Linux kernel, which will hopefully be soon. More tests will be available at that time. Until then, try out the patches yourself.

Reference: http://www.phoronix.com/scan.php?page=article&item=linux_transparent_hugepages&num=1

How to check if Hugepages are enabled in Linux

Problem: On your Linux system, you want to check whether transparent hugepages are enabled on your system.

Solution:

It’s pretty simple:

cat /sys/kernel/mm/transparent_hugepage/enabled

You will get an output like this:

always [madvise] never

You’ll see a list of all possible options ( always, madvise, never ), with the currently active option being enclosed in brackets. madvise is the default

This means transparent hugepages are only enabled for memory regions that explicitly request hugepages using madvise(2).

always means transparent hugepages are always enabled for each process. This usually increases performance, but if you have a usecase with many processes that only consume a small amount of memory each, your overall memory usage could grow drastically.

never means transparent hugepages won’t be enabled even if requested using madvise.

For details, take a look at Documentation/vm/transhuge.txt in the Linux kernel documentation.

How to change the default value

Option 1: Modify sysfs directly (the setting is reverted back to default upon reboot):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

Option 2: Change system default by recompiling kernel with modified config (this is only recommended if you’re using your own custom kernel anyway):

In order to set default to always, set these options:

CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

In order to set default to madvise, set these options:

CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
# Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

Reference: http://techoverflow.net/blog/2013/08/01/how-to-check-if-hugepages-are-enabled-in-linux/