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. 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 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.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
