On Tue, Dec 23, 2014 at 12:25 PM, Hoyer, Marko (ADITG/SW2) <mho...@de.adit-jv.com> wrote: > Some numbers to the above mentioned arguments: > - in an idle system, systemd-udev-trigger.service takes by about 150-200ms > just to get the complete device tree to send out "add" uevents again (udevd > was deactivated while doing this measure)
I'm working on optimizing this a bit (though we are obviously talking about percentage points, not orders of magnitude). I'd be interested in seeing if it could be further optimized to help your usecase once I have pushed out the basic rework. > - the processing of the resulting uevents by udevd takes 1-2 seconds (with > the default rule set) again in an idle system I haven't looked at this much recently, but if you find any bottlenecks, do shout so we can look at improving it if possible. > - in a general solution, we'd need to wait for udevd to completely settle > until we can start using the devices Hm, I would question this. In a semi-modern system you should not need to wait for settle at all, as everything should be hotplug capable. If you are in total control of your software (which I assume you are), you should be able to fix the non-hotplug capable software and drop the settling. Have you tried this? What is the blocker here? If you drop settling, then I guess the biggest tweak you can do is with the order in which devices are triggered. I'm not seeing how we can do something sensible about this in a generic fashion, but might be worth fiddling with to figure out what is the optimal order on your system (to have a baseline for future optimizations). Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
