Hi Umut, Sorry for digging out an old thread, but it appears it has not yet been answered.
On Thu, Apr 24, 2014 at 11:15 AM, Umut Tezduyar Lindskog <u...@tezduyar.com> wrote: > We are starting many services between basic.target - multi-user.target > at the same time and due to this we are suffering from following two > subjects. What can we do to overcome these problems? > > 1) We would like to start a subset of services that are scheduled to > start between basic.target - multi-user.target before the rest and > there is no built in way to satisfy our needs. The reason for this is purely scheduling, right? I looked at this sort of thing in the past (and noticed that such tweaks could indeed give quite noticeable performance benefits), however, we discussed this and I was convinced that we should not try to play such games in systemd, rather we should let the kernel do the scheduling and possibly provide it some hints (see below). > a) We could use Before=, After= on services but the downside of this > kind of dependency is we have to edit every single service file with > Before=, After= directive. This is not the best option when the subset > of services we would like to start early might change between hardware > or product configuration. That approach would probably work, but I agree it is a hack... > b) The ongoing patch > http://lists.freedesktop.org/archives/systemd-devel/2014-March/018220.html > is promising but it seems to be stopped. Any reason? Looks like the correct approach to me. Not sure what's going on with it though (if anything). > c) A service running before basic.target and queriying systemd with > "systemctl show -p [Wants Requires] default.target" and adding > Before=, After= dependency on services on runtime. Doesn't seem so > efficient. Might also work as a temporary hack, but long-term we'd hopefully get b)... > 2) Due to starting too many services and due to having frequent > context switches (flushing of caches), we see that boot time is longer > than booting services sequentially. > > a) Proposing a configuration to limit the number of jobs that are in > "activating" state. Wouldn't thes easily deadlock? Imagine you have two services on your system A and B. Each of them needs to communicate with the other it would become fully active. If your limit of active jobs is 2 there is no problem, but if it is 1 it would always deadlock... > b) "nice" value of the services can be changed to prioritize things > randomly but then we have to revert back the nice value once the boot > is completed. Doesn't seem so easy. This is basically the same as your 1.b) right? It is just a matter of setting the right sorts of scheduling priority during startup... > We are aware that our problem is mostly embedded platform specific. We > could solve our problem staticly with what systemd offers but a static > solution that is customized for one hardware is not the best solution > for another hardware. Having static solutions per hardware is > extremely hard to maintain and we would like to solve this problem > upstream instead of downstream magic. I think this sounds universally useful, and it would be cool if we could get the startup resource logic upstream... Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel