From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 10:52:08 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C052616A41F for ; Tue, 29 Nov 2005 10:52:08 +0000 (GMT) (envelope-from hiten.pandya@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB15E43D5C for ; Tue, 29 Nov 2005 10:52:07 +0000 (GMT) (envelope-from hiten.pandya@gmail.com) Received: by wproxy.gmail.com with SMTP id i3so116367wra for ; Tue, 29 Nov 2005 02:52:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UmEPsPN6YeykpIVc1iF/9yufAOF0dEuhAC/LCGA/28c/KL2EzlwcerMBrrYBBx/2Hza+d1VX6ViKXvsV/0N0Ij2dXYF2TFJSZdRKxOAdXMn1J9ZnfYx34mq82pBBQxnQcIpvvQH5beGWSrONMAKODp5sgJg1OjPNh9s/St7hLrA= Received: by 10.65.159.5 with SMTP id l5mr2805808qbo; Tue, 29 Nov 2005 02:52:07 -0800 (PST) Received: by 10.65.203.19 with HTTP; Tue, 29 Nov 2005 02:52:07 -0800 (PST) Message-ID: <9b1858120511290252w1e6d3458m@mail.gmail.com> Date: Tue, 29 Nov 2005 10:52:07 +0000 From: Hiten Pandya To: Jason Evans In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: current@freebsd.org Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2005 10:52:08 -0000 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 ? 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 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" . >