Date: Tue, 3 Jun 2003 23:26:08 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: Making a dynamically-linked root Message-ID: <20030603162607.GA64568@regency.nsu.ru> In-Reply-To: <200306031614.h53GEqkU008308@apollo.backplane.com> References: <20030602171942.GA87863@roark.gnf.org> <xzpznl02nry.fsf@flood.ping.uio.no> <20030603080456.GA57773@cirb503493.alcatel.com.au> <200306031614.h53GEqkU008308@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 03, 2003 at 09:14:52AM -0700, Matthew Dillon wrote: > > :On Mon, Jun 02, 2003 at 02:25:43PM -0700, Matthew Dillon wrote: > :> start!). Running certain daemon startups in the background might yield > :> a significant overall improvement in startup times. > :> > :> e.g. instead of running 'sshd' you would run sshd in a subshell, aka > :> (sshd &), so the RC script can continue on with the next thing without > :> having to wait for sshd to fault-in from disk. Same goes for sendmail > :> and many other daemons. > : > :This isn't a definite win. I know in the past it used to actually > :slow things down: To take your example, having both sshd and sendmail > :attempting to fault-in from disk in parallel will thrash both the disk > :and cache far more than sshd and sendmail sequentially faulting in. A > :very large number of daemons trying to start in parallel will also > :stress the scheduler. > : > :Peter > > I'm fairly sure there isn't an issue. Both a hard drive's own > on-board cache and FreeBSD's clustering and caching code are *very* well > suited to this sort of parallel initiation. There is certainly no > scheduler issue. The key advantage here is that you are removing > serialization that would otherwise cause both cpu cycles and disk > cycles to be wasted waiting for each other. Take sendmail for example. > sendmail usually takes upwards of a second to startup due to initial > DNS lookups that it makes and other things. sshd doesn't start > instantaniously either, I think due to creating the initial > session keys. Methinks that Matt's suggestion of (sshd &) and alikes does indeed sound very cool, and at least worth of reference implementation and seeing it in action. As already mentioned by Matt, the bottleneck here is not in I/O (which is, in fact, really fast nowadays) but in either network access (in case of sendmail) or (and?) CPU-intensive routines (speaking of sshd, respectively). Just my $.02 though, as it all had been already said more or less the same way by other folks. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030603162607.GA64568>