From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21627 invoked by alias); 1 Nov 2005 17:27:03 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 21610 invoked by uid 48); 1 Nov 2005 17:27:01 -0000 Date: Tue, 01 Nov 2005 17:27:00 -0000 Message-ID: <20051101172701.21609.qmail@sourceware.org> From: "sjmunroe at us dot ibm dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20051025141150.1541.sjmunroe@us.ibm.com> References: <20051025141150.1541.sjmunroe@us.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/1541] Poor threaded application performance when using malloc X-Bugzilla-Reason: CC X-SW-Source: 2005-11/txt/msg00007.txt.bz2 List-Id: ------- Additional Comments From sjmunroe at us dot ibm dot com 2005-11-01 17:27 ------- Yes arenas allocated in brk store page fault once but are effeciently reused. The problem with large allocations is that the storage allocated with mmap is unmapped with the free(). So each new allocation that exceeds the MMAP_THRESHOLD has to be faulted in. The mmap syscall does not do much work. Most of the effort of allocating the page and zeroing it out is defered until the page is actually touched the first time. This is reflected in the profiles attached above. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1541 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.