From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24953 invoked by alias); 28 Mar 2008 05:55:00 -0000 Received: (qmail 24831 invoked by uid 48); 28 Mar 2008 05:54:17 -0000 Date: Fri, 28 Mar 2008 05:55:00 -0000 Message-ID: <20080328055417.24830.qmail@sourceware.org> From: "kkylheku at gmail dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20050727134634.1128.jp-www@dcs.gla.ac.uk> References: <20050727134634.1128.jp-www@dcs.gla.ac.uk> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead 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: 2008-03/txt/msg00129.txt.bz2 ------- Additional Comments From kkylheku at gmail dot com 2008-03-28 05:54 ------- This bug can be addressed with a trivial one liner patch, which is not even in C code proper but a preprocessing directive! ROFL!!! I verified this to work on a MIPS system based on kernel 2.6.17.7 and glibc 2.5. The system boots just fine, everything seems to run, and my malloc test case shows that 1) memory is being returned to the OS by free even after sbrk fails, and 2) sbrk is not repeatedly called after it fails. (The test case simply allocates about 500 megs worth of memory in 500 byte pieces). Malloc nicely switches to an alternate arena, whereby it uses mmap to grab heaps. These heaps are nicely freed when they become deallocated, and the memory originally obtained from sbrk is nicely returned with a negative sbrk. I ran it under gdb, placing breakpoints on mmap, munap, and sbrk, and also watching the virtual memory size of the process using ps aux. --- glibc-2.5.orig/malloc/malloc.c 2006-09-07 09:06:02.000000000 -0700 +++ glibc-2.5/malloc/malloc.c 2008-04-04 01:01:32.862714704 -0800 @@ -3056,15 +3056,24 @@ (*__after_morecore_hook) (); } else { /* - If have mmap, try using it as a backup when MORECORE fails or - cannot be used. This is worth doing on systems that have "holes" in + If we have arenas, then we are basically done with this + main_arena. We can return null, because the higher level malloc + routine like public_mALLOc will try fetching from another + arena, creating one if necessary. This way we won't + cause the main_arena to become non-contiguous. + A non-contiguous main_arena has the bug that it won't return + memory to the OS when it is freed, and that it keeps + hammering away on a nonworking sbrk for each allocation request + + If have mmap, but not arenas, try using it as a backup when MORECORE fails + or cannot be used. This is worth doing on systems that have "holes" in address space, so sbrk cannot extend to give contiguous space, but space is available elsewhere. Note that we ignore mmap max count and threshold limits, since the space will not be used as a segregated mmap region. */ -#if HAVE_MMAP +#if HAVE_MMAP && !USE_ARENAS /* Cannot merge with old top, so add its size back in */ if (contiguous(av)) size = (size + old_size + pagemask) & ~pagemask; -- http://sourceware.org/bugzilla/show_bug.cgi?id=1128 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.