I was having trouble with this on a Skylake NUC (Intel graphics) running Ubuntu 15.10 (4.2 kernel). I can confirm that upgrading to 16.04 beta (4.4.6 kernel) has solved the problem. Though there still seems to be some issue with the window manager 'forgetting' about the 2nd screen's desktop upon logout/in, at least under the MATE desktop. (Display is active and the cursor travels into the space, but the background image is reset to default, and no windows can be dragged into the space or launched from there. Workaround is to go into the display settings, change something simple like which display is primary, hit apply, and it is fixed.)
@Stephen_Kitt reports that "Debian 6 was current in 2011, with kernel 2.6.32, and didn’t have transparent hugepages, it had hugetlbfs. Debian used “madvise” from 2.6.38 to 4.13, where it switched to “always”. Thus Debian 7 through 9 use “madvise”, while Debian 10 will use “always”."
Some installs of Ubuntu on servers are reported as enabling hugepages for all apps. (That is, web search finds some users asking how to disable huge pages on their Ubuntu installs :-). ). Some of these mention EC2 images specifically. @couling reports their Ubuntu server on AWS does not enable hugepages for all apps. So it seemed a bit difficult to answer for Ubuntu Server. Then I found the AskUbuntu question, "Where can I get the [Ubuntu] 11.04 kernel .config file?".
In Ubuntu 16.04, specific builds are available e.g. for AWS (Amazon Web Services). Looking at kernel version 4.4.0-125.150, the AWS kernel enabled TRANSPARENT_HUGEPAGES_ALWAYS
. However the generic kernel did not.
In Ubuntu 18.04, the generic kernel still did not enable TRANSPARENT_HUGEPAGES_ALWAYS
.
Ubuntu 11.10 was released in October 2011, and might be the first release with TRANSPARENT_HUGEPAGES
enabled. It appears to not enable TRANSPARENT_HUGEPAGES_ALWAYS
.
I think current SLES - SUSE Linux Enterprise version 15, and at least versions 12 and 11 - also match the current RHEL setting. I.e. they enable transparent hugepages for all apps.
[By implication: was LWN.net correct here, or not?]
All three of the bug reports cited by kernel developer Mel Gorman, involved a web browser affected when copying to a slow USB stick or SD card. So that point of the article is well-founded. One of the reports was "internally in SUSE". In the other two cases, it is not immediately clear where the kernel configuration came from.
As @couling pointed out, if the sysfs file shows [madvise]
, you should not say that THP is disabled altogether. It only means that THP will not applied automatically for all apps, as in the [always]
case. At least to some extent, the LWN article glossed over the distinction - the distinction between "the transparent huge pages feature is built into the kernel", and "the page fault handler will attempt to allocate a huge page", regarding a web browser which is known not to use MADV_HUGEPAGE
. It is clear that most distributors enable the former, but the latter claim is not so clear to me.
I notice that according to the source code, when you choose to enable the kernel config TRANSPARENT_HUGEPAGE
, the default config is (and has always been) to enable TRANSPARENT_HUGEPAGE_ALWAYS
.
Perhaps LWN mis-interpreted this. Or perhaps there was a brief surge of distribution kernels released with TRANSPARENT_HUGEPAGE_ALWAYS
, which were then reverted after discovering the range of potential disadvantages :-). I am not sure.
Best Answer
The distro kernels are all compiled from the official source, with distro specific patches applied. These patches are relatively minor compared to the scope of the kernel itself. As long as you know what you are doing, you can substitute a custom kernel into any of the mainstream distros, although this is discouraged since it may cause a mismatch with system header files; for that reason the distros usually release a kernel source package of their own so you can use that instead of the "vanilla" (official, unpatched) source if you want to compile it yourself.
For the same reason they release all the other software at different cycles -- to ensure everything works properly with everything else. Different distros have different policies and goals in this regard. They may hurry to get a package out as soon as the upstream source is updated, they may maintain "testing" and "stable" streams, and they may use an independent schedule.