[PC-BSD Dev] Wild idea to speed up boot process

Warner Losh imp at bsdimp.com
Tue Aug 20 20:52:34 PDT 2013

On Aug 20, 2013, at 6:34 PM, Claudio L. wrote:

> On 08/19/2013 19:41, Warner Losh wrote:
>> That's an interesting assertion. But even so, the amount of data is << 4MB,
>> so even at the slow speeds you are saving at most a second. 
> Only 4 MB? That's only config files and scripts or everything needed? What about the executable files that those scripts run? To gain any speed, those should be in RAM too.
> If you are correct and we are loading only 4 MB of data, then I'll forget about this whole thing, it wouldn't make sense.
>> The only time I've seen a big speedup, at the cost of too much memory for the environment, was when I was running off a media that got only ~150kB/s of read performance. There a RAM disk would be faster, but would eat up too much of that environment's memory. We got much larger gains from removing the /etc/rc.d files that we had disabled. And from making the underlying media speed 4x or 6x faster. The former got the boot time down from 2 minutes to ~45s seconds, while the latter I think got us to 10s (the best RAM disk boot was only 8s, so further speedups in the root device wouldn't help much more).
> Ok... so your observations are that the bottleneck is actually in running the scripts.
>> This was in a memory constrained ARM environment, which may have explained the ridiculously large win in deleting the rc files we didn't need. 
> Do you mind sharing which ARM platform (processor, speed, RAM amount, ram clock)? I'm quite familiar with a couple ARM SOC's. I'm trying to see if your bottleneck was on the scripts because you were running a slower CPU or if this may apply also to the PC. On a PC with faster CPU, the bottleneck should shift more towards the disk access, though (but I have no tests to back it, of course).

Atmel AT91RM9200, running at 180MHz (or 200MHz). 32MB RAM (which is why the memory was so constrained, but we also had boards with 64MB on it). The bottleneck was the ability to exec a script and/or programs. With other slow machines (300 or 400MHz x86), scripts ran faster, so the boot sequence took much less time.

So this is like 4 or 5 generations of ARM ago :)

>> So I'm not saying don't try, but please make careful measurements (over multiple runs) to make sure that anything you do actually has an effect. I'm skeptical that this could work out, but hey, don't let me stop you from proving me wrong :)
> The only reason I posted in the first place is to get input like yours. If you made some observations on a certain platform that tell you this is not going to work, I want to know about it before I do any work just to bang my head against a wall.
> I believe the idea has potential, but if somebody already tried something similar and doesn't work...

Given how fast PC hardware is these days, and given how much read-ahead we do, I'm skeptical that the I/O wait time is a significant part of the boot time (and that the difference between the random and sequential speeds isn't as much as you reported, I'd think).


More information about the Dev mailing list