On 05.10.2012 20:58, Bruce Dubbs wrote: > I've been looking at the boot and shutdown timing of our boot scripts. > > For boot, it seems that most of the time is taken with 'udevadm settle'. > When I instrumented the scripts, over half the boot time was waiting > for settle to complete. > > When I commented out the settle instruction, the speedup was evident: > > Oct 05 03:01:15.899727477 Starting mountvirtfs > ... > Oct 05 03:01:19.779770827 Starting SSH Server... OK > > That's 3.9 seconds for all the bootscripts I run. From dmesg, the > scripts start running a about 4.5 seconds after the kernel messages > start. That compares to 9.1 (+4.5) seconds with the settle instruction > in both udev and udev_retry. > > I'm hesitant to remove the settle instructions, but I'm also not sure > they do anything for us. Even without settle, it takes about 2 seconds > to check/mount the file systems (I mount 6) and I don't think udev > affects that. I don't really see anything after udev_retry that would > be affected either. It's possible there might be something though. > > The question here is: should the 'udevadm settle' commands be removed > from the udev and udev_retry scripts? >
I do not use sysvinit bootscripts, but here is my tought for this one. udevadm settle loads drivers built as modules. It is not always possible to build everything into kernel. Also, not everyone wants to build everything into kernel (reasons can vary). Some examples when it is not possible to build everything into kernel are mostly related to binary drivers like nVidia Binary Driver, AMD's FGLRX, Broadcom STA and possibly any other 3rd party driver. I don't think that you should disable it by default. But you can give users a choice. Introduce new variable in rc.site that can allow someone to enable/disable udevadm settle command, but enable it by default in init script. Of course, make it possible to override the var. I guess that would be fair for everyone. I am not sure where you will document this. I think everything can fit into device drivers page or whatever it's called. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
