News for hackers. Stuff that matters.
Re:Disable transparent hugepages by icebraining on Tuesday November 28, 2017 @04:50AM (#15795786)
(is it? I think it’s only a default on RHEL distros?)

I can confirm that neither my Ubuntu nor Debian servers have is in "always", they're either "madvise" or "never".

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.

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".
Re:Disable transparent hugepages by aruggirello on Tuesday November 28, 2017 @07:00AM (#15796422)
On Ubuntu 14.04/amd64 I see:

$ cat /sys/kernel/mm/transparent_hugepage/enabled

[always] madvise never

I can also confirm that my Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-101-generic x86_64) droplet has the same setting.

Re:Disable transparent hugepages by tribaal on Tuesday November 28, 2017 @07:40AM (#15796664)
The author opened a bug in Ubuntu about this here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1703742

It is in the process of being fixed (it should be set to madvise).

Re:Disable transparent hugepages by icebraining on Tuesday November 28, 2017 @07:10AM (#15796469)
Quite curious, I'm running Ubuntu 16.04.3 LTS (4.11.0-14-generic x86_64) and have "madvise".
Re:Disable transparent hugepages by jlgaddis on Tuesday November 28, 2017 @09:06AM (#15797355)
The parent said "droplet" so I assume Digital Ocean. Unless you've installed the host yourself, from scratch, you can't be sure the option hasn't been changed.

Makes me think that your setting is a default and his was set by Digital Ocean.

Re:Disable transparent hugepages by aruggirello on Tuesday November 28, 2017 @09:48AM (#15797680)
No, I have another Ubuntu 16.04 machine at home - same kernel version, same settings. He must have installed kernel 4.11 manually , because linux-image-generic currently pulls kernel 4.4.0-101-generic on 16.04; settings depend on kernel version.
Re:Disable transparent hugepages by icebraining on Tuesday November 28, 2017 @09:16AM (#15797449)
Yes, I find it interesting that DO would change random kernel flags.
Re:Disable transparent hugepages by aruggirello on Tuesday November 28, 2017 @09:59AM (#15797781)
I suspect settings actually depend on kernel version: 4.4 -> 'always', 4.11 -> 'madvise'

Perhaps there are issues with 'madvise' in kernels prior to 4.11, so they chose 'always' rather than 'never'.