Allocation latency during fork

Daniel Micay danielmicay at
Tue Nov 4 11:05:07 PST 2014

On 04/11/14 03:55 AM, Salvatore Sanfilippo wrote:
> Hello, finally I discovered the cause of the issue, so I want to follow up.
> For some reason I did not investigated, libc malloc allocates memory
> in a way does not allow transparent huge pages to work for that
> region.
> Jemalloc allocated memory instead is targeted by transparent huge
> pages, so when the feature is enabled, after fork, we have processes
> sharing the same huge pages.
> Once one of the processes starts writing to many pages in a very fast
> way, multiple page faults occur, triggering the copy-on-write of
> almost all the process space (It takes a few thousands writes to COW a
> 2GB process, for example). Since huge pages copying is slow, thousands
> of copy operations sum up to hundreds of milliseconds.
> Disabling transparent huge pages makes the problem go away.
> From the point of view of jemalloc, would be cool to have some option
> in order to mmap memory so that it is not targeted by THP regardless
> of the kernel global settings.
> Thanks,
> Salvatore

I have an issue filed about adding tunables for transparent huge page
hints with the default chunk allocator:

AFAIK huge pages are quicker to copy than the equivalent number of small
pages, but there's the overhead of compaction / defragmentation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the jemalloc-discuss mailing list