On 6/13/12 6:29 PM, Mehmet Erol Sanliturk wrote: > > > On Wed, Jun 13, 2012 at 3:49 PM, Russell Cattelan <catte...@thebarn.com > <mailto:catte...@thebarn.com>> wrote: > > On 6/13/12 2:16 AM, Poul-Henning Kamp wrote: > > In message > <alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl > <mailto:alpine.bsf.2.00.1206130909310.73...@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. > > 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 > > > > > > To reduce the boot time , my opinion is as follows : > > During install or by using a program , generate a "Hardware Profile File" . > > By editing it , mark some devices "No check" ( for example , a network > card or > PS/2 mouse or key board , is not connected , RS-232 , Firewire , > unused SATA ports , unused IDE ports , etc. , > then it is not necessary to check them . ) > > 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. > > After completion of boot , the other ports may checked to update > "Hardware Profile File" if it is requested in "Hardware Profile File" . > > Later on , assume a new device is attached . > > Run the "Hardware Profile" program to regenerate the "Hardware Profile > File" , > or by using dmesg , manually add this device into "Hardware Profile File" . > > > For removable devices , if some USB , etc. ports are not used , they all > may be > 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 background. 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. > > > I do not know such a scheme is useful or not , or usable or not . > > If I were a boot manager program writer , I would try it . > > 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 > > > Thank you very much . > > > Mehmet Erol Sanliturk > > > > >
signature.asc
Description: OpenPGP digital signature
