From owner-freebsd-arch@FreeBSD.ORG Tue Jun 3 09:57:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F284137B401 for ; Tue, 3 Jun 2003 09:57:46 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FF7E43F75 for ; Tue, 3 Jun 2003 09:57:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h53GvjVI008615; Tue, 3 Jun 2003 09:57:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h53Gvjla008614; Tue, 3 Jun 2003 09:57:45 -0700 (PDT) Date: Tue, 3 Jun 2003 09:57:45 -0700 (PDT) From: Matthew Dillon Message-Id: <200306031657.h53Gvjla008614@apollo.backplane.com> To: Paul Robinson References: <20030602171942.GA87863@roark.gnf.org> <20030603080456.GA57773@cirb503493.alcatel.com.au> <20030603163204.GA29331@iconoplex.co.uk> cc: arch@freebsd.org Subject: Re: Making a dynamically-linked root X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 16:57:47 -0000 :I'm sorry, I think I have to point something out here: : :We're talking about shaving a few seconds off a process that on a :well-maintained server happens once a week at most - i.e. a cvsupdate, :buildworld, install-kernel, reboot on a Monday morning. : :That's a few seconds a week. This is a lot of effort for shaving a few :seconds off a week. It's all well and good talking about getting rid of :"wasted cpu cycles and disk cycles" for something that happens perhaps a few :times a second, but once a week? And this is to give us a performance :advantage over Linux? Not being funny, but is this another troll thread? : :If you really want to speed up boot times because you're moving a laptop :around a lot, great, there is a possibility that an argument can be made :that someone could be looking at the serialisation of tasks that assist in :bootstrapping other processes - e.g. a dns resolver process that gets all :the "usual" hostnames into cache, key initiation stuff, etc... or of course, :we could look at getting rid of the incredibly serial rc scripts for certain :tasks so lot's of things bootstrap at once - providing dependancies are :tracked, and then we get into a discussion akin to package management. : :Interesting discussion, but are there not other areas we could look at for :performance gains? Or am I just not "getting it"? : :-- :Paul Robinson Well, not all FreeBSD installations are servers sitting in machine rooms. I have two 'kitchen terminals', both netbooted boxes (and the one in my kitchen actually boots over the wireless network). It sure would be nice if those boxes could boot up faster without too much hackery. Laptop operation is also a reasonable place where faster bootup times would be nice. In the case of the wireless netbooted box I have carefully examined the network traffic during bootup. The wireless network is not even 10% loaded for 90% of the time during the boot sequence... the delays are due to serialization of the boot process waiting for network I/O turnaround. My read is that the serialization delays are primarily due to page fault stalls and NFS. In the case of the second netbooted box, which is on a 100BaseT hardline, the same problems exist but bootup time is faster due to faster network I/O turnaround (lower latencies). In the case of a locally booted box, such as my Laptop or a normal server, bootup times are fast enough that I don't care... the kernel itself takes long to get through to the rc scripts then the rc scripts take to run. In anycase, parallelization would likely benefit these boxes. RCNG is fairly well suited to adding the capability since it already has the dependancy graph. -Matt Matthew Dillon