From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22855 invoked by alias); 12 Dec 2013 10:48:14 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 22813 invoked by uid 48); 12 Dec 2013 10:48:11 -0000 From: "siddhesh at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/11261] malloc uses excessive memory for multi-threaded applications Date: Thu, 12 Dec 2013 10:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: siddhesh at redhat dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-12/txt/msg00121.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=11261 --- Comment #19 from Siddhesh Poyarekar --- (In reply to Ondrej Bilka from comment #18) > 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 Right, but most comments on the bug report (and the resolution) are in the context of malloc creating too many arenas and the switches not working. Single allocations blocking an entire free space is not a multi-threaded problem - it occurs on single-threads too and is only compounded with multiple arenas. I'd suggest working with a fresh bug report or an open bug report that describes this problem exactly (which I'm pretty sure there should be). -- You are receiving this mail because: You are on the CC list for the bug.