Rationale for transparent_hugepage support being enabled by default?

Question

So, my machine has always seemed to be a bit less responsive that it should be for the beefy 16G RAM, SSD, i7 quad core machine that is, but I could never really pinpoint why it was slow. Chrome/Chromium would always consume CPU and sometimes lead to stuttering(ie, periods of a few seconds consuming 100% CPU across all cores).. Or VMWare would just seem extremely slow with similar stuttering. And they were always linked somehow. When Chrome stuttered, all other applications worked fine, but VMWare completely froze until Chrome started responding again. And vice-versa.
While chasing down why Chome 38 made this issue about 500% worse (to the point that I was about to forget it and install firefox instead) I was looking in top and noticed that khugepaged would use quite a bit of CPU at the same time. I googled it on a whim and came across a magical pair of instructions:
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
Suddenly, instead of VMWare idling at around 30% at all times and Chrome processes idling at 2-3% each (not to mention horrible stuttering for both), now VMWare idled at around 5%, and Chrome processes weren't even on the map.
One of my friends tried this and suddenly he saw huge performance gains as well on an Ubuntu system.
I want to understand why this is enabled by default. I tried searching for it and found a few broad overviews of what it does.. but not why it's useful, and most of the results I see (including on this forum) are all suggestions to turn it off to improve performance or avoid kernel thrashing.
Can someone tell me what transparent_hugepage support is enabled for, what applications or workflows it might make better, and why for all the problems I see in search results, it's still enabled by default?

Answer 1

Strike0 wrote:In my view the set of those default options is very sane indeed to protect Arch users with a security-wise safe default for the time being.
AFAIK, there are no security issues around Privacy Extensions... I assume you meant privacy.... If we are to patch for privacy, then we should disable javascript, cookies etc in all browsers in the official repos. That would be akin to patching for security, where we should set AllowRootLogin = no in sshd_config, and enable iptables to block all traffic by default.
Strike0 wrote:I see your points, but autoconf IPv6 addressing is one of those changes that should entail an informed opt-in IMO - at least at this time of adoption.
It's no different to connecting to a network and obtaining a DHCP lease, except more information is generated by your computer rather than a (possibly unknown/untrusted) network administrator
Strike0 wrote:Plus it is easy to change persistently.
Once you know how and what you're looking for, hence I thought it might be useful to have this thread.
Strike0 wrote:One way forward might be to add reasonably long TTL options for the temporary IPv6s in sysctl. Setting those to a time longer than the average reboot time might make away with side-effects and inefficiencies by multiple assigned temp IPs.
That could be a valid compromise in the situation. I would like to suggest setting the option to '1', but I'm not sure even what the point of this setting is since the kernel will prefer the stateless address for outgoing connections, the PE addresses would only be useful for incoming traffic, which is kind of pointless when the address will change within a very short lifetime (compared to an IPv4 address, or "static" stateless IPv6 address).