From owner-freebsd-current@FreeBSD.ORG Wed Mar 22 18:14:28 2006 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 DE09D16A425 for ; Wed, 22 Mar 2006 18:14:28 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id D63DE43D7F for ; Wed, 22 Mar 2006 18:14:25 +0000 (GMT) (envelope-from jasone@FreeBSD.org) Received: by lh.synack.net (Postfix, from userid 100) id 362755E4913; Wed, 22 Mar 2006 10:14:25 -0800 (PST) Received: from [192.168.168.201] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id AB1395E4900; Wed, 22 Mar 2006 10:14:23 -0800 (PST) Message-ID: <442193F8.7070104@FreeBSD.org> Date: Wed, 22 Mar 2006 10:14:16 -0800 From: Jason Evans User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <20060321184019.GX35129@funkthat.com> <47CC5AC0-1B44-4485-92A9-70751681A527@freebsd.org> <20060321222046.GY35129@funkthat.com> <1EB2EEE3-855C-4B76-81A6-1880526797CE@freebsd.org> <44215B1B.1080104@mac.com> In-Reply-To: <44215B1B.1080104@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.5 (2005-11-28) 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.5 Cc: John-Mark Gurney , current@freebsd.org Subject: Re: core dumps are HUGE... 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: Wed, 22 Mar 2006 18:14:29 -0000 Chuck Swiger wrote: > Can jemalloc only create per-CPU arenas only for processes which are themselves > multithreaded, when it's running on a multi-CPU system? Would that help reduce > the amount of allocated but unreferenced memory that is involved for the common > case of /bin/sh and friends? jemalloc already lazily creates arenas (and the associated chunks), so support for multi-threaded programs costs single-threaded programs practially nothing. Here's why a typical small program has a ~6 MB VSIZE on i386. Chunks have to be aligned at addresses that are multiples of the chunk size. Since the heap doesn't start at a chunk-aligned address, the first chunk that can be allocated from the heap is well past the beginning of the heap. Additionally, we need at least *two* chunks -- one for internal malloc data structures and one for application allocations. At the cost of a bit of extra complexity, it is possible to start off with a runt chunk for the internal malloc data structures, since the chunk alignment requirements happen to be unimportant for internally used chunks. This would reduce VSIZE somewhat. It isn't clear to me that this optimization is worthwhile overall (though I do have a patch that implements it). This problem doesn't even exist for the 64-bit architectures, since there we use mmap() for all chunks. Jason