Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jun 2012 12:39:57 -0500
From:      Russell Cattelan <cattelan@thebarn.com>
To:        Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: FreeBSD Boot Times
Message-ID:  <4FDA21ED.2000703@thebarn.com>
In-Reply-To: <CAOgwaMunxVxunBsMRYTtxnMjGKWmEy%2BOxgqPv_G519YR=4XgSQ@mail.gmail.com>
References:  <20336.1339571779@critter.freebsd.dk> <4FD91913.20607@thebarn.com> <CAOgwaMunxVxunBsMRYTtxnMjGKWmEy%2BOxgqPv_G519YR=4XgSQ@mail.gmail.com>

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

This is a multi-part message in MIME format.
--------------060302010302000506080701
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/13/12 6:29 PM, Mehmet Erol Sanliturk wrote:
>=20
>=20
> On Wed, Jun 13, 2012 at 3:49 PM, Russell Cattelan <cattelan@thebarn.com=

> <mailto:cattelan@thebarn.com>> wrote:
>=20
>     On 6/13/12 2:16 AM, Poul-Henning Kamp wrote:
>     > In message
>     <alpine.BSF.2.00.1206130909310.73934@wojtek.tensor.gdynia.pl
>     <mailto:alpine.BSF.2.00.1206130909310.73934@wojtek.tensor.gdynia.pl=
>>,
>     Wojci
>     > ech Puchar writes:
>     >
>     > One of the major slowdowns is that we do all the device drivers
>     > serially & synchronously.
>     Yes definitely.
>=20
>     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 bo=
ot
>     to continue on.
>=20
>     The remaining passes I'm triggering from userspace once the system
>     is up.
>=20
>     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.
>=20
>     Note systemd looks interesting from from a demand based startup sch=
eme
>     much like apples launchd. (note systemd uses linux process groups s=
o
>     porting it would take some effort)
>=20
>     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 lock=
ing
>     a bit more fine grain than the current "Giant" lock.
>=20
>     -Russell
>     >
>=20
>=20
>=20
> To reduce the boot time , my opinion is as follows :
>=20
> During install or by using a program , generate a "Hardware Profile Fil=
e" .
>=20
> By editing it , mark some devices "No check" ( for example , a network
> card or=20
> PS/2 mouse or key board , is not connected , RS-232 , Firewire ,=20
> unused SATA ports , unused IDE ports , etc. ,
> then it is not necessary to check them . )
>=20
> During boot , first read that "Hardware Profile File" .
> Only check ports marked as "Check" .
Linux does this by keeping a list of driver id's and corresponding
driver modules. The installers can then generate of list of modules
to load based on a scan done at install time.
FreeBSD is much more into build everything into the kernel vs having
a smaller kernel + modules. There really isn't anything limiting a
smaller kernel right now. I have a config with just about everything
stripped out to do multipass ordering testing and not have a ton of
extra probes going on.
>=20
> After completion of boot , the other ports may checked to update=20
> "Hardware Profile File" if it is requested in "Hardware Profile File" .=

>=20
> Later on , assume a new device is attached .
>=20
> Run the "Hardware Profile" program to regenerate the "Hardware Profile
> File" ,
> or by using dmesg , manually add this device into "Hardware Profile Fil=
e" .
>=20
>=20
> For removable devices , if some USB , etc. ports are not used , they al=
l
> may be=20
> marked as "No Check" , for example internal USB ports , unused back
> panel ports .
Making usb async would be a big help in terms of boot time it is one
of the slowest subsystems to attach.
cam already has a thread for drive scanning but unfortunately the boot
still waits for it to scan everything before proceeding.

One thing I would like to do is release the boot process once the root
drive is found and let the rest of drive discovery happen in the backgrou=
nd.
The problem that then arises is what is the next barrier point? say
when mount -a happening? Right now the rc scripts assume everything
is probed and attached. What if the rc scripts could say "load all
drives", notify me when done, get notification, run mount -a.

I was thinking anything new would have to take existing scripts and
run them normally. But provide a new framework to allow for things to
be migrated over.


>=20
>=20
> I do not know such a scheme is useful or not , or usable or not .
>=20
> If I were a boot manager program writer , I would try it .
>=20
> To my knowledge which I may be wrong , at present there is no such a
> facility .
yes something could / should be done.
So lets keep the discussion going.

-Russell

>=20
>=20
> Thank you very much .
>=20
>=20
> Mehmet Erol Sanliturk
>=20
>=20
>=20
>=20
>=20


--------------060302010302000506080701--

--------------enig7487E0E0B718E2E236DA564B
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/aIfIACgkQNRmM+OaGhBizhQCeLtMnHoMmgbr9WhpcYPJomwoe
KH4An1pBVkMonpXFNPxb05sya/bx2ngt
=qJn0
-----END PGP SIGNATURE-----

--------------enig7487E0E0B718E2E236DA564B--



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