[Discuss] khugepaged + vmware = massive CPU load

Greg Rundlett (freephile) greg at freephile.com
Fri Dec 11 07:34:17 EST 2015


On Fri, Dec 11, 2015 at 6:42 AM, Dan Ritter <dsr at randomstring.org> wrote:

> On Thu, Dec 10, 2015 at 09:31:13PM -0500, Daniel Barrett wrote:
> >
> > I don't understand much about khugepaged except that it's supposed to
> > be (ironically) a performance optimization:
> >
> >
> http://www.phoronix.com/scan.php?page=article&item=linux_transparent_hugepages
> >
> > Can anybody explain what might have been happening here, and whether I
> > am losing anything important by disabling transparent hugepages?
>
> Normally your system keeps track of memory in 4KB pages. They're
> analogous to filesystem blocks. Performance is improved when you
> can satisfy memory allocation requests with less overhead, so
> hugepages were created. A hugepage is a 2MB page.
>
> In the 2.x kernel series where they were invented, hugepages had
> to be turned on explicitly (there's a sysctl) and applications
> had to request them.
>
> Transparent hugepages are an attempt to extend the benefits of
> the reduced overhead even to applications that don't ask for
> them. Guess what? This doesn't always work.
>
> I have no transparent hugepages in use on any of the systems I
> work on, and explicit hugepages are enabled for database servers
> and some similar heavy lifters.
>
> You aren't missing anything by turning them off.
>
> -dsr-
>
> Thanks Dan for that explanation, since I knew nothing about hugepages.
Now that the serious answer is on the table, I feel more at ease turning to
humor without 'hijacking' the thread.

My answer:
Normally, you have to turn the huge page to see what's underneath.  This is
good for bedtime stories, to keep the suspense. But, it's a lot of work,
because... it's huge.   As a performance optimization, transparent huge
pages were invented so that you can see the next page without even lifting
a finger.

Ba-dum-dum, tsssh.  Thanks, I'm here all week.  Be good to the waiters.



More information about the Discuss mailing list