This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead
- From: "simberger at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 1 Oct 2009 12:03:31 -0000
- Subject: [Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead
- References: <20050727134634.1128.jp-www@dcs.gla.ac.uk>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From simberger at gmail dot com 2009-10-01 12:03 -------
Created an attachment (id=4242)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=4242&action=view)
test case
Is there any real solution for this problem? The "mallopt(M_TRIM_THRESHOLD,
(unsigned long) -1)" workaround does not work for me. It just causes every
malloc/free to result in a mmap/munmap syscall, which is even slower.
I have attached a small test program which can (kind of) work around the
problem by placing an explicit 'block buffer' behind the work buffers (set
'avoid_intelligence = true'). This would be hard to achieve in a real-world
program, though.
system info:
glibc 2.10.1-4
$ uname -a
Linux myhost 2.6.31-bfs #1 SMP PREEMPT Mon Sep 28 14:26:47 UTC 2009 x86_64
Intel(R) Core(TM)2 Duo CPU P9400 @ 2.40GHz GenuineIntel GNU/Linux
The strace output on the test program is:
brk(0xcab000) = 0xcab000
brk(0xc2b000) = 0xc2b000
brk(0xc6b000) = 0xc6b000
brk(0xcab000) = 0xcab000
(... continued ...)
--
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.