From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 16:03:46 2003 Return-Path: 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 2FC8216A4CE for ; Tue, 18 Nov 2003 16:03:46 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 1596E43FAF for ; Tue, 18 Nov 2003 16:03:45 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 3245 invoked by uid 1002); 19 Nov 2003 00:03:44 -0000 Received: from unknown (HELO ?10.4.1.5?) (64.58.1.252) by smtp.mho.net with SMTP; 19 Nov 2003 00:03:44 -0000 Date: Tue, 18 Nov 2003 17:06:06 -0700 (MST) From: Scott Long X-X-Sender: scottl@pooker.samsco.home To: dyson@iquest.net In-Reply-To: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> Message-ID: <20031118164905.R35009@pooker.samsco.home> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: "M. Warner Losh" Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 19 Nov 2003 00:03:46 -0000 On Tue, 18 Nov 2003 dyson@iquest.net wrote: > M. Warner Losh said: > > In message: <200311181307.hAID7uHa032514@dyson.jdyson.com> > > dyson@iquest.net writes: > > : It really doesn't make sense to arbitrarily cut-off a > > : discussion especially when a decision might be incorrect. > > > > I'd say that good technical discussion about why this is wrong would > > be good. However, emotional ones should be left behind. Except for > > John's message, most of the earlier messages have been more emotional > > than technical. > > > > John, do you have any good set of benchmarks that people can run to > > illustrate your point? > > > I'll see if I can find some of my old benchmarks (from memory, > not disk -- lots of stuff has rotted away.). I had hoped > to avoid doing much in the way of proof. Pointing to the > much more complex process map along with the implication > for significantly higher overhead :-). (The VM code generally > gets slower with more complex process maps and more memory used. > For smallish programs -- including those with a few shared libs, > changing the VM code won't help much, because the cost is built > in to the complexity of the process image.) I'm glad that real arguments are finally starting to surface =-) Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. 2. NSS support out-of-the-box: Again, this is a user-experience issue in that forcing NSS users to recompile world was seen as a potential roadblock to them. 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. 4. I've probably forgotten the other factors... As for performance, we felt that the typical use of FreeBSD did not fall into the category of doing forkbomb performance tests. While there might certainly be users that do continuously create lots of short-lived processes, we felt that the above benefits outweighed this, but left the door open for tailoring to this need (recompiling world with NO_DYNAMICROOT). If people really are concerned with the VM microbenchmarks associated with complex process maps, then hopefully this is a challenge to look for optimizations there. Scott