Transparent huge pages patch

[Daniel Micay]

On 12/02/15 04:22 AM, Bottiger wrote:
> Hello I am wondering if the patch here ever got merged. I could not
> find anything about it in the changelogs or on Github.
> 
> http://dev.nuodb.com/techblog/linux-transparent-huge-pages-jemalloc-and-nuodb
> 
> We experienced RSS leakage using jemalloc 3.4.1 on Linux
> 3.13.0-39-generic. It disappeared when we did echo never >
> /sys/kernel/mm/transparent_hugepage/enabled
> 
> We would prefer not to have to change a global setting.

Transparent huge pages are a significant performance win (10%+) memory
intensive workloads so disabling them across the board isn't a great
solution. AFAIK, MADV_DONTNEED will split huge pages and the kernel will
only assign new huge pages if the memory is densely packed.

I think the reason that jemalloc ends up with so many of them is the
fact that it aligns chunks to >=2MiB boundaries, so it ends up
triggering the optimistic huge page allocation for 2M aligned page
faults. I think it could just pre-fault a page per 2M at an unaligned
boundary in order to work around this, but I haven't looked into it yet.

If it's not working well even with a workaround for the 2M fault issue,
then there are bugs to report upstream.

It's actually quite good that huge allocations are huge page aligned,
because you almost always want huge pages for those (unless it's used
for a sparse data structure).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20150212/e60c28d8/attachment.sig>