On Do, 14.04.22 08:00, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> >>> Lennart Poettering <lenn...@poettering.net> schrieb am 13.04.2022 um 17:38 > in > Nachricht <YlbufcsF05NFQiUt@gardel-login>: > > On Di, 12.04.22 14:38, Elbek Mamajonov (emm.boxin...@gmail.com) wrote: > > > >> On graph I have mmcblk.device taking 1.624s. From the point that > >> this partition is where my rootfs lies, and systems does remounting > >> of rootfs, I did look up for systemd-remount-fs.service, it took > >> 231ms, and systemd-udev-trigger.service, as you suggested, it took > >> 517ms to become active. But even after systemd-udev-trigger.service > >> becomes active there is about 800ms for mmcblk.device to become > >> active. Are those services related to the activation of the > >> mmcblk.device? Can I consider those 231ms and 517ms as a part of the > >> activation time of the mmcblk.device? How can I debug udev in this > >> case? > > > > "systemd-udev-trigger.service" might take a while before it completes, > > since it triggers basically all devices in the system. > > > > It might be worth triggering block devices first. With upcoming v251 > > What is the expected benefit? On bigger servers with hundreds of disks this > may take longest. There are a myriad of devices on current systems. Traditionally, we trigger them at boot in alphabetical order by their sysfs path (more or less that is). Only once triggered subsystems waiting for them will see the devices. Since at boot typically the most waited for devices are block devices it's thus benefical to trigger them first, as this unblocks a major part of the rest of the boot process. Or in other words: nothing really "waits" for your mouse to show up in the device table. Everyting waits for your root block device to show up. Hence trigger the root block device first, and the mouse later. Lennart -- Lennart Poettering, Berlin
