From owner-freebsd-arch@FreeBSD.ORG Mon May 14 19:53:01 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51C1416A404; Mon, 14 May 2007 19:53:01 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 3669F13C458; Mon, 14 May 2007 19:53:01 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (canonware.com [64.183.146.166]) by canonware.com (Postfix) with ESMTP id 5E1A81298B4; Mon, 14 May 2007 12:24:39 -0700 (PDT) Message-ID: <4648B65A.2040803@freebsd.org> Date: Mon, 14 May 2007 12:19:54 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Robert Watson References: <20070512153532.GQ21795@elvis.mu.org> <63984.1178992555@critter.freebsd.dk> <20070513215442.GZ21795@elvis.mu.org> <46478C9A.9050807@fer.hr> <20070514132901.X24765@fledge.watson.org> In-Reply-To: <20070514132901.X24765@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Multiple malloc(3)s (was Re: HEADS DOWN) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2007 19:53:01 -0000 Robert Watson wrote: > I have to admit, > however, that I do wish we'd retained an easy switch to let us go back > and forth between phkmalloc and jemalloc for comparison purposes. It is pretty easy to go back and forth for comparison purposes, because revision 1.92 of src/lib/libc/stdlib/malloc.c is a source-compatible version of phkmalloc. You can update just that one file and get a libc with phkmalloc instead of jemalloc. I continue to make use of this for performance testing purposes, and it remains a sound strategy for diagnosing possible regressions. In my opinion, keeping only one malloc implementation in the base system was the right approach. Doing so put a lot of extra pressure on jemalloc to handle all conceivable edge cases, rather than punting here and there. (jemalloc underwent a massive redesign after it was initially committed, so there is physical evidence of how things could have gone without this pressure.) Giving users a choice between "predictable low memory usage and horribly slow multi-threaded performance", versus, "unpredictable memory usage and fast multi-threaded performance" puts users in a bad spot, because they have to choose the lesser of two evils. Jason