From owner-freebsd-performance@FreeBSD.ORG Thu Jun 26 14:51: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 0F33237B401 for ; Thu, 26 Jun 2003 14:51:54 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 944A34400F for ; Thu, 26 Jun 2003 14:51:52 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (gprs-prointernet-3e47d46b.mobile.inet.fi [62.71.212.107]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h5QLpcsL095250; Fri, 27 Jun 2003 00:51:42 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <005801c33c2d$1f0e94b0$6bd4473e@PETEX31> From: "Petri Helenius" To: "D. J. Bernstein" , References: <20030626025029.71392.qmail@cr.yp.to><200306260515.h5Q5FhPF020045@bitblocks.com> <20030626212659.51367.qmail@cr.yp.to> Date: Thu, 26 Jun 2003 23:47:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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:51:54 -0000 > > 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? > Many programmers read and write C more fluently than they do english. Code can also be run trough the common case benchmarks, proving that the improvements you suggest are not going to detoriate the 99.9%++ of users who donīt have 10000 processes. In general, not to dismiss the requirements, I think the design is broken if you require permission separation and memory separation between 10000 processes which run identical code, since that implies that either the code is badly designed, horribly broken or you expect it to be either or both. The only viable option would be that part of the executable actually comes somewhere else which kind of dismisses the optimization parameters because then the size would be unknown. Memory is cheap and FreeBSD supports 64G of it. Pete