Allocation latency during fork

[Daniel Micay]

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:

https://github.com/jemalloc/jemalloc/issues/140

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: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20141104/ea399e95/attachment.sig>