From owner-freebsd-current@FreeBSD.ORG Wed Apr 14 06:50:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BD0F416A4CE; Wed, 14 Apr 2004 06:50:37 -0700 (PDT) Received: from localhost (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i3EDobhD046284; Wed, 14 Apr 2004 09:50:37 -0400 (EDT) (envelope-from green@green.homeunix.org) Message-Id: <200404141350.i3EDobhD046284@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Peter Jeremy In-Reply-To: Message from Peter Jeremy <20040414102808.GB25565@server.vk2pj.dyndns.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Apr 2004 09:50:37 -0400 Sender: green@green.homeunix.org cc: current@freebsd.org cc: Colin Percival 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 13:50:38 -0000 Peter Jeremy wrote: > 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. Yep -- in this case, it was bsdtar, which I was unable to gain any performance from by increasing parallelism. This tells me that I/O is a contention point, but I believe it also tells me that I/O read-ahead and caching works very effectively. So for anything else with I/O as a contention point, if it is only operating on one disk there probably isn't anything to be gained with userland-created parallelism. That 6% user figure shows that sh(1) isn't really the cause of "long" boot-times. It's amazing that anything more than a minute is now too long for some people ;) > 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. This is something that Mac OS X does, but I don't know how much of the logic deciding what goes there is in Darwin to find out which disk blocks are deemed cache-worthy. > Next step is where all the kernel time is going. This probably means > running a profiled kernel or ktrace()ing into a ramdisk. Just on a hunch, someone (TM) should do a "fast-fault" mode that makes ld-elf.so.1 fully fault in any libraries it pulls in at boot-time and see how that does in populating the cache effectively with the necessary libraries instead of paging them in more slowly, with more seeking. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\