From owner-freebsd-performance@FreeBSD.ORG Thu Jun 26 14:54:02 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BCF437B401 for ; Thu, 26 Jun 2003 14:54:02 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id EADA043FEC for ; Thu, 26 Jun 2003 14:54:00 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030626215359.LZA3199.pop016.verizon.net@mac.com>; Thu, 26 Jun 2003 16:53:59 -0500 Message-ID: <3EFB6B75.3000705@mac.com> Date: Thu, 26 Jun 2003 17:53:57 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-performance@freebsd.org References: <20030626025029.71392.qmail@cr.yp.to> <200306260515.h5Q5FhPF020045@bitblocks.com> <20030626212659.51367.qmail@cr.yp.to> In-Reply-To: <20030626212659.51367.qmail@cr.yp.to> X-Enigmail-Version: 0.76.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [141.149.47.46] at Thu, 26 Jun 2003 16:53:59 -0500 cc: "D. J. Bernstein" Subject: Re: ten thousand small processes X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 21:54:02 -0000 D. J. Bernstein wrote: [ ... ] > Funny. Seems to me that I keep making concrete suggestions---including a > detailed proposal for giving more space to malloc()---and the answer is > consistently ``We really don't care about per-process overhead.'' What's > the benefit of a patch for people who don't even see the problem? Speaking for myself (rather than for others), I care about per-process overhead. The source code to FreeBSD's implementation of malloc is available at: /usr/src/lib/libc/stdlib/malloc.c If you'd like to implement your suggested changes, generate a patch (preferably via 'diff -duw'), you may either submit it as a PR via the 'send-pr' command, or you can post it to this list. It would be nice if you performed some regression testing to confirm that your change works and is beneficial not just for your specific circumstances, but for the general case as well. If you were to do these things, and then people said "We really don't care...", at that time you'd have justification for the position taken prematurely above. -- -Chuck