On Thu, 24 Dec 2020 18:55:46 +0000 Simon Hobson <li...@thehobsons.co.uk> wrote:
> Didier Kryn <k...@in2p3.fr> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
