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

Reply via email to