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: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 12 Dec 2013 08:41:51 +0000
- Subject: [Bug libc/11261] malloc uses excessive memory for multi-threaded applications
- Auto-submitted: auto-generated
- References: <bug-11261-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=11261
--- Comment #18 from Ondrej Bilka <neleai at seznam dot cz> ---
On Thu, Dec 12, 2013 at 03:31:58AM +0000, siddhesh at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=11261
>
> Siddhesh Poyarekar <siddhesh at redhat dot com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |siddhesh at redhat dot com
>
> --- Comment #17 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
> (In reply to Ondrej Bilka from comment #16)
> > > Therefore the solution to a program with lots of threads is to limit the arenas > as a trade-off for memory.
> >
> > That is a bandaid not a solution. Still there is no memory returned to
> > system when one first does allocations and then allocates auxiliary memory
> > like
>
> You have not understood the bug report.
>
When you read discussion more carefully there are following posts where
this problem is mentioned:
Ulrich Drepper:
You don't understand the difference between address space and allocated
memory.
Rich Testardi:
Actually, I totally understand the difference and that is why I mentioned the
fragmentation of memory... When each arena has just a few straggling
allocations, the maximum *committed* RAM required for the program's *working
set* using the thread-preferred arena model is, in fact, N times that required
for a traditional model, where N is the number of threads. This shows up in
real-world thrashing that could actually be avoided. Basically, if the
program is doing small allocations, a small percentage of stragglers can pin
the entire allocated space -- and the allocated space is, in fact, much larger
than it needs to be (and larger than it is in other OS's). But thank you for
--
You are receiving this mail because:
You are on the CC list for the bug.