Huge page support would be useful in JEMalloc

[Jeff Hammond]

On Mon, Dec 1, 2014 at 3:25 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Kenneth Steele <ken at ezchip.com> wrote:
>> Ideally, JEMalloc with Huge pages would be the best.
>
> For some apps such as yours, yes.  And jemalloc can already use
> transparent hugepages, but there are downsides to apps (e.g. redis)
> which fork:
>
>   http://mid.gmane.org/CA+XzkVfZV36k-d6mw9xEBgSQQhmfMKwts79wrwMB+3PYydzeCg@mail.gmail.com
>
> Not sure if there's an automatic, best-of-both worlds approach...

Large pages are widely known to be a win in high-performance
computing, e.g. Cray supercomputers.  Not that anyone sane forks
(outside of program launch) in HPC programs, but you can't do it if
you want to in Cray Linux anyways (at least the last time I read the
docs).  Same story for Blue Gene, but since Blue Gene doesn't run
Linux, there are a different set of issues to consider in the context
of jemalloc.

The positive effective of large pages on TLB misses are pretty
obvious, but there are plenty of papers written about this topic if
people need evidence.  TLB misses are more common than fork() in all
of the codes where I care about performance...

I'm optimistic that https://github.com/memkind will let me exploit
large pages on Cray machines, but I haven't had time to try it yet.

Best,

Jeff

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/