From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 11:42:57 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 5E62F16A41F for ; Tue, 29 Nov 2005 11:42:57 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B27043D5C for ; Tue, 29 Nov 2005 11:42:55 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.2] (S0106000f3d63befd.vs.shawcable.net [70.71.19.119]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id jATBbX8A088838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2005 12:37:51 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <438C3D7C.3000704@portaone.com> Date: Tue, 29 Nov 2005 03:37:32 -0800 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Jason Evans References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.2/1198/Tue Nov 29 11:05:20 2005 on www.portaone.com X-Virus-Status: Clean X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.0 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on www.portaone.com Cc: current@FreeBSD.ORG Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com 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 11:42:57 -0000 Just curious what is the grand plan for this work? I wonder if it will make sense to have two malloc's in the system, so that user can select one which better suits his needs. -Maxim 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 > > === 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="aj" . > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > >