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
Hi.
(Not sure if it's still pertinent.)
On Tue, Apr 07, 2020 at 10:23:22AM +0530, nitish nagesh
wrote:
> 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
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
On Do, 02.04.20 18:51, nitish nagesh (nagesh.nit...@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
Am 02.04.20 um 15:21 schrieb nitish nagesh:
> 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
