[systemd-devel] what's the order in which systemd .device units are created ?

[Abder]

>
> > Hi,
> >
> > Even though I've browsed through a lot of resources I haven't found any
> > satisfying answer to my question. I've been trying to minimize the
booting
> > time in the user land on my embedded board, and when I run the classic
> > $systemd-analyze plot > plot.svg I saw that there is a non-negligible
slot
> > of time in which all what systemd does is creating device units that
were
> > discovered via udev.
> >
> > My problem is in the order in which these device units are created,
> > specially for the block device that contains my rootfs. What I noticed
is
> > that when these device units are created, the one corresponding to my
> > rootfs blockdev partition is always the last one created, causing the
other
> > services depending on it to wait much more than if the device unit was
> > created earlier.
> >
> > So, I would like to know if systemd follows a special order when
creating
> > these units, and if yes, what can I do so the device unit of my rootfs
> > blockdev partition can be the first one created ?
>
> The systemd-udev-trigger.service unit invokes "udevadm trigger" to
> trigger all devices that are already discovered by the kernel at that
> point. PID 1 listens to that and synthesizes .device units from all
> devices popping up. The order in which "udevadm trigger" triggers them
> is pretty much the order in which readdir() returns the devices when
> iterating through /sys/, i.e. basically undefined.
>
> There's a github issue open somewhere where I proposed adding a new
> switch to "udevadm trigger" called --priorize-subsystem=… or so, which
> you can use to priorize on or more subsystems: any subsystems listed
> that way are triggered first. That way you could do "udevadm trigger
> --priorize-subsystem=block" to ensure block devices are triggered
> first (in fact, we probably should use this as default once we have
> the concept, given that the most relevant devices we wait for at boot
> are probably all block device). Would be happy to review/merge a patch
> for that.

Can't we already achieve this using the udevadm trigger filters
i.e. --subsystem-match= ?

> Note that the order in which devices are triggered does not directly
> translate to the order in which devices actually are processed and
> make it through udevd and are picked up by PID 1. udevd runs rules for
> each device, and if those are slow and take a bit of time, this might
> delay delivery of the events to PID 1. However, there's certainly some
> relationship here: if certain devices are the ones we start processing
> first thy are likely also the devices where we finish processing them
> first, even if there's no strict guarantee for that.

I also like to mention that even if the block device is triggered earlier
in systemd-udev-trigger.service (using the  --subsystem-match= ), sometimes
the creation of the corresponding device unit is delayed. I noticed a delay
of  0.8 to 1.5 seconds between the time systemd-udev-trigger.service became
active and the time systemd started creating .device units.

I'm no expert in systemd and how PID 1 synthesizes the .device units
from udev, but if I understood correctly your suggestion regarding
prioritization, I think the implementation needs to be also on the systemd
side. An example of such implementation can be the definition of a new udev
keyword that one can use inside udev rules to mark devices that need to be
prioritized by systemd.

--
Thank you for your reply, I appreciate it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210602/74a2b9ca/attachment-0001.htm>