Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jun 2012 17:49:55 -0500
From:      Russell Cattelan <cattelan@thebarn.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD Boot Times
Message-ID:  <4FD91913.20607@thebarn.com>
In-Reply-To: <20336.1339571779@critter.freebsd.dk>
References:  <20336.1339571779@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB838464551549E703833768C
Content-Type: multipart/mixed; boundary="------------050802040009090709000206"

This is a multi-part message in MIME format.
--------------050802040009090709000206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 6/13/12 2:16 AM, Poul-Henning Kamp wrote:
> In message <alpine.BSF.2.00.1206130909310.73934@wojtek.tensor.gdynia.pl=
>, Wojci
> ech Puchar writes:
>=20
> One of the major slowdowns is that we do all the device drivers
> serially & synchronously.
Yes definitely.

I have been looking into how to potentially defer or parallelize
device_attach'es. Defer is turning out to be hard enough since each
system is has different requirements to reach a state where it can
run /sbin/init. I've started with the John Baldwin's multipass work
and have a system stops probing/attaching devices and allows the boot
to continue on.

The remaining passes I'm triggering from userspace once the system is up.=


This is all very crude at this point and has been an some work just
to understand how the kernel startup code all links together.

Note systemd looks interesting from from a demand based startup scheme
much like apples launchd. (note systemd uses linux process groups so
porting it would take some effort)

Ideally it would be nice to get to the point where many devices are only
attached once there is a demand for it. Say network interfaces for
example: attach it once the init scripts need to config it and then
hopefully in an async fashion. Unfortunately that will require locking
a bit more fine grain than the current "Giant" lock.

-Russell
>=20


--------------050802040009090709000206--

--------------enigB838464551549E703833768C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/ZGRMACgkQNRmM+OaGhBhdWACfdiYT9Jn+xELa3qOnK8FNm20Y
lX0An1l2IuHPa50ZGNORnqL/f3E6XcFW
=OSKA
-----END PGP SIGNATURE-----

--------------enigB838464551549E703833768C--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD91913.20607>