Interaction of udev with the init subsystem

Interaction of udev with the init subsystem

[Ozan Çağlayan]

Hi,

I'm maintaining the udev package for Pardus, a GNU/Linux distribution
mainly developed in Turkey.

After doing some investigations of the startup time on our distribution,
I've figured that udev related invocations takes a lot of time.

1) The startup of the daemon is quick enough, no problem here,
2) The first trigger+settle takes ~4.5 seconds to complete.

We're currently using udev-126 but I also tried 137, and the performance
is quite the same.

I wonder what are the points that a distribution packager/maintainer should consider
when starting/stopping udev for having the best startup time.

My second question is about the orphaned rule files left in /dev/.udev
after triggering the event processing on a read-only root filesystem. I'm succesfully
collecting those rules, moving them into /etc/udev/rules.d and recalling trigger
after mounting the root filesystem read-write. If I don't retrigger,
no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains
a media during boot. Retriggering here takes ~0.11 seconds.

It would be very nice to have a detailed documentation for udev beside rule writing stuff.

Thanks,

-- 

Ozan Çağlayan
<ozan_at_pardus.org.tr>

Re: Interaction of udev with the init subsystem

[Greg KH]

On Mon, Mar 02, 2009 at 11:09:39PM +0200, Ozan Çağlayan wrote:
> Hi,
> 
> I'm maintaining the udev package for Pardus, a GNU/Linux distribution
> mainly developed in Turkey.
> 
> After doing some investigations of the startup time on our distribution,
> I've figured that udev related invocations takes a lot of time.
> 
> 1) The startup of the daemon is quick enough, no problem here,
> 2) The first trigger+settle takes ~4.5 seconds to complete.
> 
> We're currently using udev-126 but I also tried 137, and the performance
> is quite the same.

It's the modprobe stuff that is taking most of the time, right?  That's
not udev.

> I wonder what are the points that a distribution packager/maintainer should consider
> when starting/stopping udev for having the best startup time.
> 
> My second question is about the orphaned rule files left in /dev/.udev
> after triggering the event processing on a read-only root filesystem. I'm succesfully
> collecting those rules, moving them into /etc/udev/rules.d and recalling trigger
> after mounting the root filesystem read-write. If I don't retrigger,
> no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains
> a media during boot. Retriggering here takes ~0.11 seconds.
> 
> It would be very nice to have a detailed documentation for udev beside rule writing stuff.

Patches are always gladly welcome :)

thanks,

greg k-h

Re: Interaction of udev with the init subsystem

[Kay Sievers]

On Mon, Mar 2, 2009 at 22:09, Ozan Çağlayan <ozan@pardus.org.tr> wrote:
> I'm maintaining the udev package for Pardus, a GNU/Linux distribution
> mainly developed in Turkey.
>
> After doing some investigations of the startup time on our distribution,
> I've figured that udev related invocations takes a lot of time.
>
> 1) The startup of the daemon is quick enough, no problem here,
> 2) The first trigger+settle takes ~4.5 seconds to complete.

Run "udevadm monitor" during that time, and check which of the events
is blocking the "settle" for that long.

> My second question is about the orphaned rule files left in /dev/.udev
> after triggering the event processing on a read-only root filesystem. I'm succesfully
> collecting those rules, moving them into /etc/udev/rules.d and recalling trigger
> after mounting the root filesystem read-write. If I don't retrigger,
> no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains
> a media during boot. Retriggering here takes ~0.11 seconds.
>
> It would be very nice to have a detailed documentation for udev beside rule writing stuff.

I don't think there is much more you need to do, than you do already.

It very much depends on the specific distro setup, like some mount the
rootfs rw, so there are no rules to move around, and a single coldplug
run does all needed work.
Some systems support things like /usr on a different disk, which has
its very own set of problems, which will likely get harder over time
to support, because we got more and more udev consumers which rely on
/usr to be always around, and so on ...

Kay