From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 07:06:14 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 B316516A423 for ; Tue, 29 Nov 2005 07:06:14 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9052943D5A for ; Tue, 29 Nov 2005 07:06:11 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 9EA5D5E48F4; Mon, 28 Nov 2005 23:06:06 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 1E1DA5E48B0 for ; Mon, 28 Nov 2005 23:06:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: current@freebsd.org From: Jason Evans Date: Mon, 28 Nov 2005 23:05:57 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Subject: 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 07:06:14 -0000 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" .