Bruce Dubbs wrote: > 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.
/dev/disk/by-{id,label,path,uuid}/*
Also I'm pretty sure that UUID=foo or LABEL=foo in fstab still use these
paths indirectly (by-uuid and by-label, respectively).
If you use /dev/sd??, then I wish you the best of luck the next time the
kernel's disk discovery order changes. Because it's not guaranteed to
remain the same forever, and so when it changes, your system won't be
bootable. :-)
I will also note that using /dev/disk/by-id/ links allowed me to survive
the IDE -> libata transition (/dev/hd* to /dev/sd*) with zero userspace
changes.
>>> 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.
Still need it for /var, for alsactl. :-/
> 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.
Hmm, I thought that was empty by default... Nope, it seems it does have
rtc in there. Huh.
Oh right, hwclock needs /var/lib/hwclock/adjtime doesn't it.
I wonder if that one can not settle by default. The only thing that will
require the system time to be set from the RTC by hwclock is NTP, which
might be far enough down the road (after networking comes up) that it's
OK to just let it go.
Another option would be to try to figure out why it's waiting so long,
but I'm not sure how to do that.
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
