Disable transparent hugepages

Re:Disable transparent hugepages by glandium on Tuesday November 28, 2017 @05:16AM (#15795907)

FWIW, Debian 9 (stretch) has it set to "madvise", but my Debian unstable machine has it to "always". Looking further, I can see that /boot/config-4.12.0-1-amd64 has:

  # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

and /boot/config-4.13.0-1-amd64 has:

  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set

So this is a recent change.

Edit: The linux kernel source says the default is always (in mm/Kconfig), and that's been true since 2011.

The debian package changelog says the change occurred in 4.13.4-1:

  * thp: Enable TRANSPARENT_HUGEPAGE_ALWAYS instead of
    TRANSPARENT_HUGEPAGE_MADVISE

The reason is not given in the changelog itself, but it's given in the git log of the debian packaging:

As advised by Andrea Arcangeli - since commit 444eb2a449ef "mm: thp: set THP defrag by default to madvise and add a stall-free defrag option" this will generally be best for performance.

https://anonscm.debian.org/cgit/kernel/linux.git/commit/debi...

Edit 2: The mentioned commit (444eb2a449ef) dates back to 4.6, so presumably, at least some performance issues with transparent huge pages may be gone since that version of the kernel.

[ Parent | on HN ]

Re:Disable transparent hugepages by mrob on Tuesday November 28, 2017 @07:16AM (#15796505)

Interesting. I'm running Debian unstable, and recently my system would sometimes lock up under heavy memory pressure. I'm using VirtualBox, which has its own kernel module, so I can't be sure Linux itself is to blame, but the timing seems to coincide with when I switched to that kernel version. Maybe transparent hugepages uncovered a VirtualBox bug or even a kernel bug. And I care about worst case performance more than average performance, so I just now set it to "never".

[ Parent | on HN ]