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).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
