[systemd-devel] Start-up resource and prioritization control
teg at jklm.no
Thu May 15 02:47:23 PDT 2014
Sorry for digging out an old thread, but it appears it has not yet
On Thu, Apr 24, 2014 at 11:15 AM, Umut Tezduyar Lindskog
<umut at 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
> 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
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...
More information about the systemd-devel