Branch: Tag:

2012-08-17

2012-08-17 13:35:25 by Henrik Grubbström (Grubba) <grubba@grubba.org>

Runtime: Tune malloc(3C) in glibc. Alleviates [bug 6045 (#6045)].

Malloc(3C) in glibc defaults to having one pool (aka arena) of memory
per thread. This means that by default memory released by one thread
will not be reused by another thread. This in turn can cause a "pumping"
effect where one thread temporarily may use a lot of memory, which
causes that thread's arena to grow. If the same code is run again later,
but by a different thread, that threads arena will grow even though
there's plenty of free memory in the old arena. This means that there's
a multiplication effect by the number of active threads.

This implements the suggested work-around from the similar bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=11261

316:   #endif   #endif    + #ifdef HAVE_MALLOPT +  TRACE((stderr, "Init malloc...\n")); +  +  /* The malloc implementation in recent glibc (eg Linux) +  * defaults to using one arena / thread. This means that +  * memory once allocated from one thread can't later be +  * allocated by another thread. +  * +  * cf [bug 6045] and http://sourceware.org/bugzilla/show_bug.cgi?id=11261 +  * +  * We try to alleviate the problem by reducing the number +  * of arenas as much as possible. +  */ +  + #ifdef M_ARENA_TEST +  /* NB: Some versions of glibc don't support setting M_ARENA_TEST to 0. */ +  /* Note also that the test is inverted since mallopt returns 0 on success. */ +  mallopt(M_ARENA_TEST, 0) && mallopt(M_ARENA_TEST, 1); + #endif + #ifdef M_ARENA_MAX +  mallopt(M_ARENA_MAX, 1); + #endif + #endif /* HAVE_MALLOPT */ +     TRACE((stderr, "Init master...\n"));       find_lib_dir(argc, argv);