From owner-freebsd-current@FreeBSD.ORG Fri Jul 18 12:29:37 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E405B1065678 for ; Fri, 18 Jul 2008 12:29:37 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 595318FC0C for ; Fri, 18 Jul 2008 12:29:36 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6ICTYoQ025370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Jul 2008 14:29:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6ICTU4b024226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2008 14:29:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6ICTU9d047833; Fri, 18 Jul 2008 14:29:30 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6ICTSE2047832; Fri, 18 Jul 2008 14:29:28 +0200 (CEST) (envelope-from ticso) Date: Fri, 18 Jul 2008 14:29:28 +0200 From: Bernd Walter To: Peter Jeremy Message-ID: <20080718122928.GD35340@cicely7.cicely.de> References: <200807172056.08835.naylor.b.david@gmail.com> <487FCA89.2010308@FreeBSD.org> <20080718083725.97823be0tg13fn6s@webmail.leidinger.net> <20080718071806.GV62764@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080718071806.GV62764@server.vk2pj.dyndns.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.150, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Alexander Leidinger , Doug Barton , David Naylor , freebsd-current@freebsd.org Subject: Re: rc improvements (wanted?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 12:29:38 -0000 On Fri, Jul 18, 2008 at 05:18:07PM +1000, Peter Jeremy wrote: > On 2008-Jul-18 08:37:25 +0200, Alexander Leidinger wrote: > >Are you aware that the parallel starting in Solaris 10 reduced the > >booting time by a nice percentage? > > Given that Solaris boots in geologic time, this probably wouldn't > be difficult. > > > If yes, do you expect that FreeBSD > >behaves significantly different or do you "just" want to see numbers? > > Parallel starting is not guaranteed to be an improvement. Starting a > whole pile of processes that are I/O bound during initialisation > (think squid or some databases) may be worse than starting them one > at a time. Likewise, a whole pile of processes that are CPU bound > will just thrash the scheduler. (Though parallel starting of I/O and > CPU bound processes should be a win). Speaking about small systems, where startup time is more a problem than on 08/15 desktop and server systems. What I would love to see is that scripts like moused, ypserv, lpt, etc are not started if the services are disabled. So far each script is started, sucks in routines plus rc.conf then possibly does nothing reasonable after wasting some seconds boottime. Of course I can remove the scripts, but you'll never know if you need one of them at a later time and having the right set of scripts can become tricky. Parallel however doesn't sound interesting for me, since those systems are CPU and memory bound, so I don't see a possible win, maybe even a degration if memory restricts. > >Sidenote: Even if there's no significant speedup, the possibility to > >start things in parallel should be provided, this would allow more > >experimentation (at all respectively later). > > Agreed. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.