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>