Date: Tue, 3 Jun 2003 09:14:52 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: arch@freebsd.org Subject: Re: Making a dynamically-linked root Message-ID: <200306031614.h53GEqkU008308@apollo.backplane.com> References: <20030602171942.GA87863@roark.gnf.org> <xzpznl02nry.fsf@flood.ping.uio.no> <20030603080456.GA57773@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
: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.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306031614.h53GEqkU008308>