This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/1128] Malloc not trimming filled-up sbrk space causes unnecessary system call overhead


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]