[systemd-devel] Process ordering within a 'dependency level'

[Lennart Poettering]

On Fri, 07.03.14 10:52, Allmeroth, Robert (robert.allmeroth at harman.com) wrote:

> Hi,
> 
> I tried to optimize my embedded configuration but I stumbled over the following problem:
> 
> Let's assume systemd identified 10 processes on 'dependency level
> 0'. They all can/should be started first/immediately.  Since they
> cannot be started at the same time - they start sequential with some
> little delay.
> 
> But one of that processes is in the critical chain in the meaning that
> half of the system depends on it.  So.. that process must be started
> first (instead of being started at pos 10 of 10) to avoid all the
> little start delays + data loading of the already started 9 processes.
> 
> Is there a way to express / force an ordering of unit files within one
> dependency level?  Means: I would like to tell systemd the order in
> which processes have to be started without using a forced wait like
> 'After' (that causes often idle CPU and I/O)

If multiple units are runnable at the same time it is undefined which
one is started first. Note however, that PID 1 fork()s off those
processes and doesn't wait for them to respond before going on to the
next one. The work done within PID 1 there is hence very cheap.

Note that for cases where only Type=simple services are used you can
declare the fork() order by simple After=/Before= dependencies. However,
as soon as you use any other Type= this will also delay the units until
after the forked off processes responded back to PID 1.

I'd be willing to merge a patch that adds RunPriority= or so, which
takes some numeric priority value and which could influence which unit
is processed first if multiple are runnable. But I'd prefer some
performance data with it that shows that this actually makes a
measurable difference.

Did you see the StartupCPUShares= patches recently posted on the ML? To
me they appear much more useful to optimize specific boot processes as
they simply pass all ordering logic into the kernel CPU and IO
schedulers as quickly as possible and let the kernel figure things out
which should normally be better at these things than us.

Lennart

-- 
Lennart Poettering, Red Hat