1

I am puzzled by LWN again.

Huge pages, slow drives, and long delays -- LWN.net, 2011

It is a rare event, but it is no fun when it strikes. Plug in a slow storage device - a USB stick or a music player, for example - and run something like rsync to move a lot of data to that device. The operation takes a while, which is unsurprising; more surprising is when random processes begin to stall...

A process (that web browser, say) is doing its job when it incurs a page fault ... If the transparent huge pages feature is built into the kernel (and most distributors do enable this feature), the page fault handler will attempt to allocate a huge page.

I can see that on Red Hat Enterprise Linux, transparent hugepages are enabled as described by LWN.

How to use, monitor, and disable transparent hugepages in Red Hat Enterprise Linux 6 and 7?

Transparent Huge Pages (THP) are enabled by default in RHEL 6 for all applications...

For RHEL 7 see How to disable transparent hugepages (THP) on Red Hat Enterprise Linux 7. For RHEL 8 see How to disable transparent hugepages (THP) on Red Hat Enterprise Linux 8. [Links to content for subscribers only].

However, I looked on my Fedora Workstation 29 laptop, and I see transparent hugepages are not enabled "for all applications".

$ cat /sys/kernel/mm/transparent_hugepage/enabled 
always [madvise] never
$ uname -r
4.19.13-300.fc29.x86_64

I also checked in some VMs: I see the same on Ubuntu Desktop 18.04 (kernel 4.15.0-43-generic), and on a Debian 9 Desktop install (kernel 4.9.0-8-amd64). (And I don't believe Debian has a "Server" install, spin, or package. It just has a few different "tasks" to install the most common server softwares. So I don't think there is any one place in Debian that could be enabling a server-specific configuration).

  1. Does Fedora Server 29 enable transparent hugepages for all apps?
  2. Does Ubuntu Server 18.04 enable transparent hugepages for all apps?
  3. Did a different version number of one of these distributions enable transparent hugepages for all apps, e.g. around 2011?

[By implication: was LWN.net correct here, or not? And if it was correct to say that most distributors enabled transparent hugepages, and imply that it affected some common "desktop" (or laptop) setups, do we know why current versions of Fedora Workstation, Debian, and Ubuntu Desktop are not enabling transparent hugepages for all?]

  • madvise is still enabled. But it's not "system wide". See kernel.org/doc/Documentation/vm/transhuge.txt FYI, I just checked my ubuntu server on AWS and it is also set to madvise. – Philip Couling Jan 21 at 16:43
  • @couling right, presumably an app can ask for transparent hugepages, using the madvise() call if it is enabled. But I don't have any hugepages. So my browser clearly isn't asking for them. Contra the LWN example, a page fault in my browser will not try to allocate a hugepage. So I am trying to guess what made LWN think this was a good example to illustrate the problem... – sourcejedi Jan 21 at 16:47
  • @couling Thanks for pointing out the ambiguity in the title I used! Particularly since it looks like this might be what LWN was confused about. I have edited my question to use the specific phrasing from the RHEL doc. – sourcejedi Jan 21 at 16:54
  • 1
    Debian had THP enabled by default from kernel 2.6.38 to 4.13, so the kernels for Debian 7 to 9 had it set to “always”. Debian 10 will have it set to “madvise”. Debian 6 was current in 2011, with kernel 2.6.32, and didn’t have transparent hugepages, it had hugetlbfs. – Stephen Kitt Jan 21 at 16:54
  • 1
    Sorry, I got things mixed up; 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”. – Stephen Kitt Jan 21 at 17:04
0

@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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.