This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11261] malloc uses excessive memory for multi-threaded applications
- From: "rich at testardi dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 10 Feb 2010 13:41:58 -0000
- Subject: [Bug libc/11261] malloc uses excessive memory for multi-threaded applications
- References: <20100208202339.11261.rich@testardi.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rich at testardi dot com 2010-02-10 13:41 -------
Hi Ulrich,
Agreed 100% no one size fits all...
Unfortunately, the neither of the "tuning" settings for MALLOC_ARENA_MAX nor
MALLOC_ARENA_TEST seem to work. Neither do mallopt() M_ARENA_MAX nor
M_ARENA_TEST. :-(
Part of the problem seems to stem from the fact that the global "narenas" is
only incremented if MALLOC_PER_THREAD/use_per_thread is true...
#ifdef PER_THREAD
if (__builtin_expect (use_per_thread, 0)) {
++narenas;
(void)mutex_unlock(&list_lock);
}
#endif
So the tests of those other variables in reused_arena() never limit anything.
And setting MALLOC_PER_THREAD makes our problem much worse.
static mstate
reused_arena (void)
{
if (narenas <= mp_.arena_test)
return NULL;
...
if (narenas < narenas_limit)
return NULL;
I also tried all combinations I could imagine of MALLOC_PER_THREAD and the
other variables, to no avail. I also did the same with mallopt(), verifying
at the assembly level that we got all the right values into mp_. :-(
Specifically, I tried things like:
export MALLOC_PER_THREAD=1
export MALLOC_ARENA_MAX=1
export MALLOC_ARENA_TEST=1
and:
rv = mallopt(-7, 1);
printf("%d\n", rv);
rv = mallopt(-8, 1);
printf("%d\n", rv);
Anyway, thank you. You've already pointed me in all of the right directions.
If I did something completely brain-dead, above, feel free to tell me and save
me another few days of work! :-)
-- Rich
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11261
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.