From owner-freebsd-performance@FreeBSD.ORG Fri Jun 27 04:41:54 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 A5C8137B401 for ; Fri, 27 Jun 2003 04:41:54 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10F7E43FFD for ; Fri, 27 Jun 2003 04:41:54 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc155.dialup.mindspring.com ([209.86.4.165] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Vrc0-0000JL-00; Fri, 27 Jun 2003 04:41:52 -0700 Message-ID: <3EFC2CDE.8AE25B2C@mindspring.com> Date: Fri, 27 Jun 2003 04:39:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "D. J. Bernstein" References: <20030626025029.71392.qmail@cr.yp.to> <20030626212659.51367.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a439570a2132878fd7e55a25471eb70422350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-performance@freebsd.org 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: Fri, 27 Jun 2003 11:41:54 -0000 "D. J. Bernstein" wrote: > Bakul Shah writes: > > Instead of complaining about wasting 78 megabytes and arguing > > about why various proposed solutions fall short and why your > > way is the best, why don't you come up with a patch that > > saves space for small programs? > > 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? Your "concrete proposal for malloc" made a number of bad assumptions: o "UVA == 4G", rather than "UVA + KVA == 4G" Costs to move to "UVA == 4G": o pages must be mapped before each copy of data across a protection domain o pages must be unmapped afterwards o If we had access to another 2G of UVA, we'd have no better use for it than to make malloc more space efficient My answer, at least, was "too computationally expensive for a general purpose OS when making the size/computational overhead tradeoff". -- Terry