|
From: William S. <wsc...@ak...> - 2007-11-14 17:10:40
|
Thank you both for the info. This definitely helps me figure out where to go next. Howard Chu wrote: >Tom Hughes wrote: > > >>In message <473...@ak...> >> William Schauweker <wsc...@ak...> wrote: >> >> >>>My suspicion is that it is the standard library allocator holding onto >>>blocks of memory for reuse. >>> >>> >>It could be the standard C++ library hanging on to it, but that >>should show up in valgrind. More likely it is glibc hanging on to >>it as malloc/free don't normally return freed memory to the system. >> >> > >Actually, blocks larger than a certain size are usually returned to the >system. The default threshold in glibc 2.5 is 128K; malloc requests of this >size or larger are satisfied using mmap() and the mmap'd regions are unmapped >when freed. > >By the way, tuning this threshold can have a noticeable impact on the degree >of fragmentation in the heap, and can help malloc's performance on some workloads. > >http://sourceware.org/ml/libc-alpha/2006-03/msg00033.html > >The tests I reported here http://highlandsun.com/hyc/malloc/ >all used the default glibc settings. glibc may have fared better in these >tests if I had used a larger threshold but I haven't had time to re-test. > > |