On Fri, Dec 11, 2015 at 6:42 AM, Dan Ritter <[email protected]> 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. _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
