Date: Wed, 14 Apr 2004 20:28:09 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Colin Percival <colin.percival@wadham.ox.ac.uk> Cc: current@freebsd.org Subject: Re: Optimizing RCng execution speed ? Message-ID: <20040414102808.GB25565@server.vk2pj.dyndns.org> In-Reply-To: <6.0.1.1.1.20040414065121.039cde20@imap.sfu.ca> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040414102808.GB25565>