From owner-freebsd-current@FreeBSD.ORG Wed Apr 14 03:28:16 2004 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 6A67C16A4CE for ; Wed, 14 Apr 2004 03:28:16 -0700 (PDT) Received: from mail003.syd.optusnet.com.au (mail003.syd.optusnet.com.au [211.29.132.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E91543D5C for ; Wed, 14 Apr 2004 03:28:15 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i3EAS9419764; Wed, 14 Apr 2004 20:28:09 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i3EAS9Ru025794; Wed, 14 Apr 2004 20:28:09 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i3EAS9Aw025793; Wed, 14 Apr 2004 20:28:09 +1000 (EST) (envelope-from peter) Date: Wed, 14 Apr 2004 20:28:09 +1000 From: Peter Jeremy To: Colin Percival Message-ID: <20040414102808.GB25565@server.vk2pj.dyndns.org> References: <11095.1081621779@critter.freebsd.dk> <407B1EBC.6050405@freebsd.org> <407B234D.7070209@kientzle.com> <20040413160331.GM6308@numachi.com> <20040413200013.GC53327@cirb503493.alcatel.com.au> <6.0.1.1.1.20040414065121.039cde20@imap.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.1.1.1.20040414065121.039cde20@imap.sfu.ca> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: Optimizing RCng execution speed ? 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, 14 Apr 2004 10:28:16 -0000 On Wed, Apr 14, 2004 at 07:54:11AM +0100, Colin Percival wrote: >At 21:00 13/04/2004, Peter Jeremy wrote: >>If someone wants to have a look at this, >>the place to start is to profile the complete system during startup >>and see where the time is going. > > On my 5.2.1 system (with the mentioned don't-reload-rc.subr patch): >Starting RC scripts: kern.cp_time: 1 0 44 2 53 ... >RC scripts done: kern.cp_time: 71 0 455 5 819 Overall, that's 61% idle, 33% sys and 6% user. I suspect the 'idle' time is virtually all waiting for disk I/O. Someone else (green@ ?) has commented that increasing parallelism slowed things down - which is consistent with system startup being I/O bound. This doesn't seem too unlikely: - The system is starting from cold so the filesystem cache is empty. Most read(2) calls and page-faults will require physical I/O. - Many of the scripts just spawn a daemon process. These generally daemonise fairly early and do most of their startup in the background - colliding with all the other daemons doing the same thing. It may sound counter-intuitive but adding some judicious short sleeps (a few ticks each) during startup could speed things up by reducing the disk contention. The other option is to add a kernel hook(s) that records physical disk reads into a file and then uses that file to pre-load the filesystem and VM cache (in sequential order rather than randomly). This assumes enough RAM to be able to load all the necessary disk blocks - but that is probably the norm nowadays. Next step is where all the kernel time is going. This probably means running a profiled kernel or ktrace()ing into a ramdisk. Peter