You are not logged in.

#1 2014-11-03 21:33:15

earlz
Member
Registered: 2010-07-11
Posts: 39

Rationale for transparent_hugepage support being enabled by default?

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?

Offline

Board footer

Powered by FluxBB