Bryan Kadzban wrote: > Armin K. wrote: >> 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. > > They don't in udev_retry by default. It certainly wouldn't hurt to rip > out the settle call if the sysconfig file doesn't retry any subsystems. > > On the other hand, if the sysconfig file doesn't retry any subsystems, > then I'd be surprised if settle was taking any time at all. It *should* > just be a sequence-number comparison, and it should finish immediately. > >>> 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. > > Well, no, it doesn't. udevadm trigger sends the uevents that cause that > to happen. Running settle just waits for udevd to handle all the events > that the kernel has sent when settle gets called. (And udevd waits for > events for child devices as well, when it knows they exist.) > > At least one settle call is required before checking the filesystems, > because /etc/fstab probably refers to persistent device symlinks (if > not, you're asking for problems when the kernel decides to discover your > disks in a different order), and those symlinks don't exist before udevd > handles the event for the disk/partition/whatever-it-is. So without a > settle call, the checkfs script will probably die.
What symlinks? I use /dev/sd?? and those are not symlinks. I do have /dev/cdrom in fstab, but that's noauto and wouldn't need a checkfs anyway. I don't use a usb disk; perhaps that uses symlinks. > It also helps with network renaming since we're still doing that, or > some other form of network persistence like the crazy findif script I > put together a while back and then never put into the contrib/ directory > anywhere. (Because the data used to find NICs might not be in the udev > db, or the names might have been assigned backwards.) Not an issue if > you only have one NIC of course. I did think about the nic issue. >> 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. > > This sounds fine I think. Yes, that seems like a good compromise. Perhaps two variables; one for the udev script and one for the udev_retry script. We could even disable the udev_retry script completely if /usr is a part of the root partition. The only thing udev_retry does by default is trigger the rtc subsystem but just that takes 4-5 seconds to settle on my system. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page