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