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

Warner Losh imp at bsdimp.com
Mon Aug 19 16:41:54 PDT 2013

On Aug 19, 2013, at 5:28 PM, Claudio L. wrote:
> On 08/19/2013 15:43, Warner Losh wrote:
>> Two issues here:
>> (1) The buffer cache will make reading off media as fast as reading from RAM (since you need to load the RAM, and the delta in compression is likely tiny since configuration data from /etc is tiny). I'm not sure it would help much in the boot time.
> What makes me think (and hope) it will, is the random read speed vs sequential read speed. A normal HD can do 120 MB/s sequential, but about 4 MB/s random, and that's where the improvement will come from.

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.

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). 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.

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 :)

> I'm not only thinking about /etc, but almost everything needed for booting, including executable files and everything else.
> Or perhaps I'm looking at it wrong, and what we really need to do is find a way to persist the disk cache across reboots (?).

If you are pre-loading everything, then you're likely loading way more than's necessary.

Chances are quite good that the selective loading the buffer cache is doing will be a big win over that. Persisting the cache across boots is silly, since it is supposed to be (basically) the most recently used stuff.

But one of the big areas of time may be shared libraries, which I/O buffering won't help a lot on.

>> (2) NanoBSD has a mechanism to cope with all the issues that you are talking about here. You might want to look at what it does. It doesn't bother with unionfs, preferring instead to load the "known good" configuration from persistent media into RAM and running from there (although there's a minor issue with /etc/master.passwd when users change their passwords).
> I didn't know that. I'll definitely look at their code before attempting anything.
> Thanks for the hint!
> Claudio
> _______________________________________________
> Dev mailing list
> Dev at lists.pcbsd.org
> http://lists.pcbsd.org/mailman/listinfo/dev

More information about the Dev mailing list