Hi,
In fact i did try a similar approach of assigning CPUShares to a slice. Basically i separated these critical services into a new slice & assigned a CPUShare=8192. However with this i see it takes more time than before to complete the boot. One related observation was, on my system the default value of CPUShares was not 1024 (as mentioned in the man-pages). Instead its a large number.
# systemctl show system-netns.slice | grep -i cpu
CPUUsageNSec=192379569
CPUAccounting=yes
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
CPUUsageNSec=192379569
CPUAccounting=yes
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
So by setting it to 8192 am I reducing the CPUShare and hence seeing an increase in time? I tried the same with StartupCPUShares but observations were similar. The DefaultCPUAccounting also seems to be enabled for the system.
Am i doing something incorrectly here? Please help.
This is the systemd version is use:
# systemctl --version
systemd 229
+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN
+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN
Thanks,
On Thu, Apr 2, 2020 at 8:00 PM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On Do, 02.04.20 18:51, nitish nagesh (nagesh.nitish@xxxxxxxxx) 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,
StartupCPUWeight= and StartupIOWeight= are probably what you should be
using? Have you played around with that? That passes this problem on
to the CPU/IO schedulers of the kernels. i.e. you still enqueue
everything in parallel, but tell the kernel what to schedule first.
In recent systemd versions the weights configured this way also affect
the order in which jobs are dispatched by systemd itself if multiple
are runnable at the same time.
Lennart
--
Lennart Poettering, Berlin
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
