From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22748 invoked by alias); 9 Feb 2010 16:02:14 -0000 Received: (qmail 18043 invoked by uid 48); 9 Feb 2010 16:01:59 -0000 Date: Tue, 09 Feb 2010 16:02:00 -0000 Message-ID: <20100209160159.18040.qmail@sourceware.org> From: "rich at testardi dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20100208202339.11261.rich@testardi.com> References: <20100208202339.11261.rich@testardi.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/11261] malloc uses excessive memory for multi-threaded applications X-Bugzilla-Reason: CC 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 X-SW-Source: 2010-02/txt/msg00054.txt.bz2 ------- Additional Comments From rich at testardi dot com 2010-02-09 16:01 ------- 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 your time -- we all want the same thing here, a ever better Linux that is more suited to heavily threaded applications. :-) -- 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.