apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: reducing memory fragmentation
Date Sun, 20 Feb 2011 19:00:28 GMT
On Sunday 20 February 2011, Jim Jagielski wrote:
> On Feb 19, 2011, at 2:57 PM, Stefan Fritsch wrote:
> > I am sure that apr_allocator with mmap is not an advantage on all
> > platforms. Actually, apr allocating only multiples of 4k should
> > make it easier for malloc to avoid fragmentation. But glibc's
> > malloc fails miserably in that regard.
> 
> Is there a way during configuration time that we can do
> some rough testing on "best" multiple to use...?

I don't know about the "best" multiple. One would probably have to do 
benchmarks for that. But it is possible to check for mallocs that 
behave similar to glibc's malloc. If several allocated chunks are not 
allocated with distances that are a multiples of the page size, the 
malloc is inefficient.

But before activating such a configure check, I would wait for some 
feedback from some people using the mmap option in real-world.

For glibc/i386, the attached test program gives:

$ ./malloc_test ; echo $?
pagesize: 4096
minalloc: 8192
malloc offset: 8
1

If you force glibc to use mmap, the result is different. But i don't 
know how efficient glibc is in this mode:

$ MALLOC_MMAP_THRESHOLD_=8192 ./malloc_test ; echo $?
pagesize: 4096
minalloc: 8192
malloc offset: 0
0

On FreeBSD amd64:
$ ./malloc_test ; echo $?
pagesize: 4096
minalloc: 8192
malloc offset: 0
0

On non-mainstream hardware (Linux glibc/ia64)
$ ./malloc_test ; echo $?
pagesize: 16384
minalloc: 16384
malloc offset: 16
1

On Linux i386 with tcmalloc:
$ LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.0.0.0 ./malloc_test ; 
echo $?
pagesize: 4096
minalloc: 8192
malloc offset: 0
0

But AFAIK tcmalloc is not a good general choice either, because it 
will never give memory back to the OS.

Mime
View raw message