From owner-freebsd-current@FreeBSD.ORG Sat Dec 3 07:50:27 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 A36F216A41F for ; Sat, 3 Dec 2005 07:50:27 +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 87B5743D46 for ; Sat, 3 Dec 2005 07:50:26 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 8E24F5E4895; Fri, 2 Dec 2005 23:50:25 -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 8F9735E47E5; Fri, 2 Dec 2005 23:50:20 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Fri, 2 Dec 2005 23:49:37 -0800 To: Jon Dama 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: 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: Sat, 03 Dec 2005 07:50:27 -0000 On Nov 29, 2005, at 12:06 PM, Jon Dama wrote: > There exists a problem right now--localized to i386 and any other arch > based on 32-bit pointers: address space is simply too scarce. > > Your decision to switch to using mmap as the exclusive source of > malloc > buckets is admirable for its modernity but it simply cannot stand > unless > someone steps up to change the way mmap and brk interact within the > kernel. There's a new version of the patch available at: http://www.canonware.com/~jasone/jemalloc/jemalloc_20051202b.diff This version of the patch adds the following: * Prefer to use sbrk() rather than mmap() for the 32-bit platforms. * Lazily create arenas, so that single-threaded applications don't dedicate space to arenas they never use. * Add the '*' and '/' MALLOC_OPTIONS flags, which allow control over the number of arenas. As of this patch, all of the issues that were brought to my attention have been addressed. This is a good time for additional review and serious benchmarking. Thanks, Jason