Comment Disk seeks are the real culprit? (Score 2, Interesting) 625
I've seen the exact opposite approach taken - switching from parallel to serial to reduce startup times.
The reason this worked was that starting processes in parallel increased disk contention and the extra seeks brought the machine to a crawl.
Sure, that was on a system with very slow seek times, and not much in the way of disk caching and scheduling (an Amiga 500 with no HD). A lot of things have improved since then, but seeks are still extremely slow in machine terms, and we also have virtual memory and demand page loading which I imagine don't help the problem.
Maybe keeping data needed at startup centralised on the disk (e.g. in the boot partition) would help.
As disk accesses during startup are probably pretty predictable (consistent from one boot to the next), it may be possible to pre-load the disk cache to improve startup times.
A simple approach would be to log disk blocks accessed during startup, and then read them (in a sensible order of course, and in parallel across disks) at the start of the next boot.
The reason this worked was that starting processes in parallel increased disk contention and the extra seeks brought the machine to a crawl.
Sure, that was on a system with very slow seek times, and not much in the way of disk caching and scheduling (an Amiga 500 with no HD). A lot of things have improved since then, but seeks are still extremely slow in machine terms, and we also have virtual memory and demand page loading which I imagine don't help the problem.
Maybe keeping data needed at startup centralised on the disk (e.g. in the boot partition) would help.
As disk accesses during startup are probably pretty predictable (consistent from one boot to the next), it may be possible to pre-load the disk cache to improve startup times.
A simple approach would be to log disk blocks accessed during startup, and then read them (in a sensible order of course, and in parallel across disks) at the start of the next boot.
