<div dir="ltr">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.<div><br></div><div>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. <br><div><br></div><div>We didn't use startup IO shares because we are based on ubifs which back then didn't have IO scheduler support. </div></div><div><br></div><div>Hope it gives some inspiration.</div><div>Umut</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 3:21 PM nitish nagesh <<a href="mailto:nagesh.nitish@gmail.com">nagesh.nitish@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi folks,<div><br></div><div>  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.</div><div><br></div><div>  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.</div><div><br></div><div>   Separating daemons into buckets could be done using: </div><div>1) systemd targets: Introduce 2 new targets and classify the services/daemons into them. Layer these targets during boot.</div><div>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.</div><div><br></div><div>Can you please suggest which of the above is a better approach? Respective pros/cons with each.</div><div><br></div><div>Or if there is a third approach better than the above?</div><div><br></div><div>Thanks in advance,<br></div></div>
_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div>