On Do, 12.07.18 16:51, Paul Menzel (pmenzel+systemd-devel at molgen.mpg.de) wrote: > Dear systemd folks, > > > Trying to decrease the start-up time, I noticed that `systemd-logind` > probes devices in serial(?) (instead of parallel). > > From `manager_enumerate_buttons(Manager *m)` in `src/login/logind.c`: > > ``` > udev_list_entry_foreach(item, first) { > _cleanup_(udev_device_unrefp) struct udev_device *d = NULL; > int k; > > d = udev_device_new_from_syspath(m->udev, udev_list_entry_get_name(item)); > if (!d) > return -ENOMEM; > > k = manager_process_button_device(m, d); > if (k < 0) > r = k; > } > ``` > > The macro is defined as below: > > ``` > /** > * udev_list_entry_foreach: > * @list_entry: entry to store the current position > * @first_entry: first entry to start with > * > * Helper to iterate over all entries of a list. > */ > #define udev_list_entry_foreach(list_entry, first_entry) \ > for (list_entry = first_entry; \ > list_entry != NULL; \ > list_entry = udev_list_entry_get_next(list_entry)) > ``` > > Is there a way to do that in parallel? systemd components are generally single threaded. Probing input devices from systemd is unlikely to be a performance problem. I mean, we don't process 10K devices here, but usually not more than 25 or so... Also the code isn't really CPU or IO bound here, it just does a few open() and ioctl() calls mostly. Before spending time on optimizing anything like this: did you did profiling on this, that shows clearly that this is performance relevant at all? Lennart -- Lennart Poettering, Red Hat