[systemd-devel] Start-up resource and prioritization control

[Tom Gundersen]

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
<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
> 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