On Thu, 24 Dec 2020 18:55:46 +0000
Simon Hobson <linux@???> wrote:

> Didier Kryn <kryn@???> wrote:
>
> > Therefore I suspect the authors managed to launch several threads
> > in order to save 0.01s of the boot time. Or to loose more because
> > thread scheduling might well consume more than what parallelism
> > saves.
>
> In the general case, parallelism only saves wall clock time IFF you
> have a number of processes that have to wait on outside events while
> not (significantly) using resources on the machine - or if they are
> exceedingly computationally intensive that running tasks across
> multiple cores gives a saving (not common during startup). So if you
> have things like bringing up interfaces - waiting for WiFi to connect
> and DHCP to get an address, that sort of thing. But even then there's
> probably little to be saved since you usually have most of the system
> waiting for the network to be up before it can proceed. But
> otherwise, especially with a spinning disk, parallelism will slow
> things down because you force the disk to go off here there and
> everywhere getting data for different processes. Not applicable
> during startup, but there are memory considerations* too if the jobs
> are large. With SSD this is much less of a problem.

The preceding is a great argument for using the Epoch init system.
Epoch has no facilities for parallel instantiation, so booting is
determinate.

The reasons I use runit instead of Epoch are:

* Epoch has no respawn capability
* I don't think Epoch is maintained anymore.

My experiments with Epoch indicate its boot time was in the same
ballpark as runit and systemd.

SteveT

Steve Litt
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive