From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 21 22:27:34 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1348C106564A; Thu, 21 Jun 2012 22:27:34 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id B21F68FC08; Thu, 21 Jun 2012 22:27:33 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q5LMRQ2C021869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2012 08:27:27 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q5LMRJUF092417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 08:27:19 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q5LMRHBe092416; Fri, 22 Jun 2012 08:27:17 +1000 (EST) (envelope-from peter) Date: Fri, 22 Jun 2012 08:27:17 +1000 From: Peter Jeremy To: Doug Barton Message-ID: <20120621222717.GA91640@server.rulingia.com> References: <20120615124849.GI96212@ass.kameli.org> <20120618081140.GK96212@ass.kameli.org> <4FDF6177.5050608@unsane.co.uk> <4FDF6586.9060501@gentoo.org> <4FDFB166.2040709@FreeBSD.org> <4FDFB761.60406@brandonfa.lk> <20120621122802.GA71656@server.rulingia.com> <4FE3552D.9090202@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <4FE3552D.9090202@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" Subject: Re: Replacing rc(8) (Was: FreeBSD Boot Times) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 22:27:34 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jun-21 10:09:01 -0700, Doug Barton wrote: >On 06/21/2012 05:28 AM, Peter Jeremy wrote: >> 32.0s - rc scripts ("mounting root" through VTY login prompt) > >I think that there is some confusion about what I wrote originally, so >let me clarify. From the time that /etc/rc starts through the time that >the prompt appears almost all of the time is spent waiting for the >services to start. There is very little time spent IN the rc scripts >themselves (barring something that is poorly written of course). Agreed - I (and I expect everyone else) am using "rc script" to cover the total wall time between exec()ing the script and it returning - in most cases, this is almost entirely synchronous service startup time. The end-user experience is governed by "how long does it take between rebooting or turning the power on and when I can login or interact with my service". Reducing this total time is going to require a combination of changes in multiple areas. One point I'd make is that the rc scripts run with cold caches so reads cause physical I/O. There are somewhat over 150 scripts in /etc/rc.d and a variable number in /usr/local/etc/rc.d (I have between 6 & 33 on different systems). rcorder(8) needs to read each script so, on a system using spinning rust, this amounts to 2-3 seconds overhead. >So the only way to improve the time from /etc/rc to "usable system" >(whatever that means for the user) is to see what we can parallelize. >The problem is that this is a really hard problem. :) And as someone >pointed out, changing from a serial to a parallel process is going to be >disruptive because it will uncover the inadequately specified >dependencies that we have now which are hidden by the serial process ... (I mentioned this problem). One (though intrusive) way would be to use the approach the ports system used when it enabled parallelism within port builds: Add new keyword(s) within each script to control parallelism for that script. Initially, the infrastructure would assume "serial" unless scripts were explicitly marked "parallel" or "background" but once the situation was sufficiently under control, it could be flipped to assume "parallel" unless a script specifically specified "serial". (Note that I haven't looked at the detail of actually implementing this). As an aside, "usable system" is a relevant point. My Netbook originally came with Linpus and it took about 30s from poweron until the Linpus GUI was displayed and allowed user interaction. This looked quite impressive but it took another 30-60s before the system was actually usable because the GUI was started quite early before (eg) the network was up. --=20 Peter Jeremy --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/jn8UACgkQ/opHv/APuIeqFACfesMz98jnmMtYHmKiM7owYW0V jycAni6lXI65KLqPQxWjHJgNNkxIH/TE =w575 -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--