Judging from my tests (allocating numerous small objects, then freeing the memory) it looks like the bottleneck is in free(). I've built a different libc library with the malloc.c and tree.h taken from HEAD and it now behaves nicely. I haven't seen any bad side effects on this machine (it's the lappie I do most of my work on, I run KDE, seamonkey, mplayer, openoffice, the like) since I switched to the new libc. Another nice solution would be to ship the modified libc in base so the people who really need jemalloc can relink to it via libmap.conf. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.
In the last episode (Oct 05), Vlad GALU said:> Judging from my tests (allocating numerous small objects, then > freeing the memory) it looks like the bottleneck is in free(). I've > built a different libc library with the malloc.c and tree.h taken > from HEAD and it now behaves nicely. I haven't seen any bad side > effects on this machine (it's the lappie I do most of my work on, I > run KDE, seamonkey, mplayer, openoffice, the like) since I switched > to the new libc. Another nice solution would be to ship the modified > libc in base so the people who really need jemalloc can relink to it > via libmap.conf.You can compile just the -current version of malloc.c as a shared object, then inject it into specific binaries: $ gcc -O -Wall -I/usr/src/lib/libc/include -shared -o /lib/jemalloc.so jemalloc.c $ MALLOC_OPTIONS=P date date in malloc(): warning: unknown char in MALLOC_OPTIONS Thu Oct 5 11:44:36 CDT 2006 $ LD_PRELOAD=/lib/jemalloc.so MALLOC_OPTIONS=P date |& head Thu Oct 5 11:44:49 CDT 2006 ___ Begin malloc statistics ___ Number of CPUs: 2 Number of arenas: 11 Chunk size: 524288 (2^19) Quantum size: 16 (2^4) Max small size: 512 Pointer size: 4 Assertions enabled Allocated: 4096, space used: 1048576 I've tried this with seamonkey and mysqld, so this method seems to work fine on complex apps. -- Dan Nelson dnelson@allantgroup.com