[systemd-devel] Grouping services in systemd..

[Umut Tezduyar Lindskog]

We had a similar problem and we solved it by using grouping for critical
services and then using startup cpu shares for services that should be
responsive within that group.

Even if you use startup cpu shares and create a target for everything you
would want to boot, some unnecessary services will get the CPU due to CFS.
Them getting CPU is by itself a problem, also they would cause a context
switch with memory caches being flushed. To avoid this, we have created a
target for our critical services and their dependencies. We had yet another
service inside this critical group which told systemd to kick off
multi-user.target when critical services were up.

We didn't use startup IO shares because we are based on ubifs which back
then didn't have IO scheduler support.

Hope it gives some inspiration.
Umut

On Thu, Apr 2, 2020 at 3:21 PM nitish nagesh <nagesh.nitish at gmail.com>
wrote:

> Hi folks,
>
>   We are working on an embedded ARM Cortex A9 based system (aka low CPU).
> It runs on a custom linux based operating system which uses systemd.
>
>   We have a bunch of daemons (around ~50+) that come up during boot
> simultaneously which slows down the boot significantly as the CPU runs out
> of breath. We were thinking of staggering these daemons into 2 groups. The
> first group containing "critical" daemons (around 15) so that they finish
> faster and make the system usable sooner. Followed by the second group of
> daemons.
>
>    Separating daemons into buckets could be done using:
> 1) systemd targets: Introduce 2 new targets and classify the
> services/daemons into them. Layer these targets during boot.
> 2) Cgroups: Create a new systemd slice and put all the "critical" services
> into it. Allocate sufficient CPUShares value to the slice so that this
> slice gets its due CPU% to finish faster boot.
>
> Can you please suggest which of the above is a better approach? Respective
> pros/cons with each.
>
> Or if there is a third approach better than the above?
>
> Thanks in advance,
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200609/0d2d4af4/attachment.htm>