From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 16:21:59 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 13F5916A4CE; Tue, 18 Nov 2003 16:21:59 -0800 (PST) Received: from dyson.jdyson.com (dsl-static-206-246-160-137.iquest.net [206.246.160.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id A281643FBD; Tue, 18 Nov 2003 16:21:57 -0800 (PST) (envelope-from toor@dyson.jdyson.com) Received: from dyson.jdyson.com (localhost [127.0.0.1]) by dyson.jdyson.com (8.12.8/8.9.3) with ESMTP id hAJ0LjXQ000833; Tue, 18 Nov 2003 19:21:46 -0500 (EST) (envelope-from toor@dyson.jdyson.com) Received: (from toor@localhost) by dyson.jdyson.com (8.12.8/8.12.8/Submit) id hAJ0Lj5e000832; Tue, 18 Nov 2003 19:21:45 -0500 (EST) Message-Id: <200311190021.hAJ0Lj5e000832@dyson.jdyson.com> In-Reply-To: <20031118164905.R35009@pooker.samsco.home> from Scott Long at "Nov 18, 2003 05:06:06 pm" To: scottl@freebsd.org (Scott Long) Date: Tue, 18 Nov 2003 19:21:45 -0500 (EST) From: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: dyson@iquest.net 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 Reply-To: dyson@iquest.net 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:21:59 -0000 Scott Long said: > 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. > /bin and /sbin don't need to contain everything :-). Adding a full featured /rescue should also help to counterbalance this (but maybe the upgrade would be selective?) There are reasons for /usr/bin and /usr/sbin (along with /usr/local, /usr/share.) Disk space is CHEAP and grandfathering 20MB hard drives (or the yr2000 equivalent of 4GB hard drives) is nice -- but repartitioning them with more reasonable root allocations seems like a good idea anyway :-). 50MB root was silly when 2-4GB disks were common. Continuing to pay for a poorly made partitioning decision in the past seems to be unworthy (in my opinion.) > > 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. > The cool thing about properly implemented shared libs is that not everything has to be shared. Even the kernel supports runtime loading/addition of modules, and the NSS sounds like a good candidate for a library feature. Burdening everything with the sparse .data associated with libc seems to be a waste (but, perhaps the performance that was carefully crafted into the codebase is no longer important?) Really -- it is possible that performance isnt' important anymore, and fully accepting the ongoing loss of performance for features (without careful tradeoffs) might be an appropriate strategy. (In the case of the NSS stuff, it shouldn't require everything to be built dynamic.) > > 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. > The additional hole of exploiting the system through the shared libs is a negative tradeoff. > > 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. > Nope - even shell execution times (e.g. long shell scripts) will see a difference. Prejudicial comments like 'fork-bombs' and 'microbenchmarks' aren't really fair. Proper benchmarking is time consuming and analysis is tricky. System loading conditions are difficult to control (for experiments.) Note that alot of the lost performance is hidden by the VM code (e.g. one of the purposes for prezeroing on SMP box -- before SMP was fine grained.) The cost of sparse data and needless inheritance of modified pages has performance hits that are incredibly difficult to accurately (and honestly) measure. Anyone can create 'preordained' benchmark results. This is one reason why I am loathe to get into the FreeBSD performance game again -- it is much more difficult than a few micro-benchmarks :-) that simply measure a fork exec time. John