:: Re: [DNG] Detailed technical treati…
Top Page
Delete this message
Reply to this message
Author: Simon Hobson
Date:  
To: dng@lists.dyne.org
Subject: Re: [DNG] Detailed technical treatise of systemd
Rainer Weikusat <rainerweikusat@???> wrote:

> ... but the conclusion is "Whoever believes parallelization beyond starpar will improve 'booting speed' for this machine is sadly mistaken".


I've done no measurements, but my "gut feeling" is that for the servers I manage (and my OS X laptop), the limiting factor is disk I/O. Thus parallelising service startup won't help much (if at all) because it just means all the services fire up and take longer each to start. Eg, (as a simplification) if you have 10 services that take 10s each to start, then they'll take 100s total - starting them in parallel probably means they'll all take 100s (give or take). All assuming no dependencies of course !

Of course, it's possible for some workloads to take longer in parallel. Having (taking the above example) 10 services all accessing the disk means losing the benefit of any file contents locality on the disk - so instead of reading a file in one go, the disk may head off elsewhere at some point (to service one of the other services that's starting) and have to come back to read the rest of the file.

I de recall in a previous job we had some Apollo Domain systems - that dates it, they were 68020 based IIRC. Upstairs, the naval architects had a bigger machine for number crunching finite element analysis*. To start with, the system was "fairly open", but a few engineers abused it and they had to lock it down. In the end, jobs had to be submitted and one of the admins ran them - separately. Before the lockdown, people would just fire up their own jobs which could mean things like swapping out and the jobs took longer than if run sequentially. In the worst case, one or two people actually went as far as killing other peoples jobs to get theirs running !


Where parallel startup will help is if you have a lot of cpu intensive tasks - and then (and only then) will those interleave execution with those waiting on disk I/O. Can't say I've noticed many of my services being particularly CPU bound during startup.


And back to an earlier comment about the difference between "booted" as in shows a login or the desktop and "booted" as in "can actually be used ...
On my Mac, I get the desktop fairly quickly but the machine isn't usable. I have a fair bit of software set to auto start as I always use it (eg mail programs and such), or the system will auto start the programs that were running before the last reboot. Even after programs have stopped launching (so it's possible to do anything without the foreground application changing), the machine isn't usable as it's just so sluggish - anything needing disk I/O (which is just about anything immediately after a reboot) just has to fight it out in the I/O queue.
I have to sit there, with the disk rattling quietly away to itself, for what seems like a couple of minutes between the desktop appearing and the machine actually being usable.

As for my servers, I don't reboot them very often and normal start times aren't an issue - far more of an issue is fsck times if it's been a long time since the last reboot or an uncontrolled shutdown. Having daemons start predictably and reliably is far more important than shaving an odd second off here or there. Besides, (on bare metal) there's all that BIOS stuff that happens before the OS even gets a look-in - I sometimes wonder if Dell and HP have a competition on how long they can make this process !


* I vaguely recall that at the time being told that it was a toss up between Apollo and Sun - but Apollo had the higher spec number cruncher at the time and that's what swung it. I wasn't involved all that much, I was just a user back then.