From owner-freebsd-current@FreeBSD.ORG Mon Apr 12 15:02:09 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 B310316A4CE for ; Mon, 12 Apr 2004 15:02:09 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320A043D2F for ; Mon, 12 Apr 2004 15:02:09 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i3CM20gF031445; Mon, 12 Apr 2004 17:02:00 -0500 (CDT) (envelope-from dan) Date: Mon, 12 Apr 2004 17:02:00 -0500 From: Dan Nelson To: Colin Percival Message-ID: <20040412220200.GD19655@dan.emsphone.com> References: <11095.1081621779@critter.freebsd.dk> <20040411083611.GA63990@stud.fit.vutbr.cz> <6.0.1.1.1.20040412223815.043a2e68@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.20040412223815.043a2e68@imap.sfu.ca> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: current@freebsd.org cc: Divacky Roman 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: Mon, 12 Apr 2004 22:02:09 -0000 In the last episode (Apr 12), Colin Percival said: > At 09:36 11/04/2004, Divacky Roman wrote: > >RCng uses dependancies so it naturally makes a graph where some > >nodes are independant of each other. what about executing this in > >parallel? > > I've put together some code for this -- I hacked up rcorder to > output sets of scripts which can be run simultaneously, had rc.subr > run them in the background, and had /etc/rc wait after each group. > Much to my surprise, it didn't help -- in fact, it resulted in a 5% > slowdown (on my single processor, HTT-enabled system). This may be due to (at least watching my systems boot up) the delay being mainly disk waits. Running things in parallel just ends up thrashing your boot disk. Some way to determine the blocks accessed during bootup and prefetching them would help the most, I think. You could probably get geom to log the disk block numbers, but I'm not sure how you would cache them. Some new sysctl in the vfs.ffs.* area, maybe? -- Dan Nelson dnelson@allantgroup.com