Date: Tue, 29 Nov 2005 10:52:07 +0000 From: Hiten Pandya <hiten.pandya@gmail.com> To: Jason Evans <jasone@canonware.com> Cc: current@freebsd.org Subject: Re: New libc malloc patch Message-ID: <9b1858120511290252w1e6d3458m@mail.gmail.com> In-Reply-To: <B6653214-2181-4342-854D-323979D23EE8@canonware.com> References: <B6653214-2181-4342-854D-323979D23EE8@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason, I see that you have included an implementation of red-black tree CPP macros, but wouldn't it be better if you were to use the ones in <sys/tree.h> ? I have only had a precursory look, but I would have thought that would be the way to go. Just a suggestion. Best regards, -- Hiten Pandya hmp at freebsd.org On 29/11/05, Jason Evans <jasone@canonware.com> wrote: > There is a patch that contains a new libc malloc implementation at: > > http://www.canonware.com/~jasone/jemalloc/jemalloc_20051127a.diff > > This implementation is very different from the current libc malloc. > Probably the most important difference is that this one is designed > with threads and SMP in mind. > > The patch has been tested for stability quite a bit already, thanks > mainly to Kris Kennaway. However, any help with performance testing > would be greatly appreciated. Specifically, I'd like to know how > well this malloc holds up to threaded workloads on SMP systems. If > you have an application that relies on threads, please let me know > how performance is affected. > > Naturally, if you notice horrible performance or ridiculous resident > memory usage, that's a bad thing and I'd like to hear about it. > > Thanks, > Jason > > =3D=3D=3D Important notes: > > * You need to do a full buildworld/installworld in order for the > patch to work correctly, due to various integration issues with the > threads libraries and rtld. > > * The virtual memory size of processes, as reported in the SIZE field > by top, will appear astronomical for almost all processes (32+ MB). > This is expected; it is merely an artifact of using large mmap()ed > regions rather than sbrk(). > > * In keeping with the default option settings for CURRENT, the A and > J flags are enabled by default. When conducting performance tests, > specify MALLOC_OPTIONS=3D"aj" . >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9b1858120511290252w1e6d3458m>