We all know how annoying it is that today's much faster computers take such a long time to boot, and OS developers are working on speeding it up. Some time ago I proposed a defragmenter that notice what blocks were read in what order at boot and put the contiguous on the disk. I was told that experiments with this had not had much success, but more recently I read reports of how the latest Linux distributions will boot as much a 3 times faster on solid state disks as on rotating ones. There are some SSDs with performance that high (and higher) but typical ones range more in the 120 mb/second rate, better than 80 mb/second HDDs but getting more wins from the complete lack of latency.

However, today I want to consider something which is a large portion of the boot time, namely the power-on-self-test or "POST." This is what the BIOS does before it gets ready to load the real OS. It's important, but on many systems is quite slow.

I propose an effort to make the POST multitask with the loading of the real OS. Particularly on dual-core systems, this would be done by having one core do the POST and other BIOS (after testing all the cores of course) and other cores be used by the OS for loading. There are ways to do all this with one core I will discuss below, but this one is simple and almost all new computers have multiple cores.

Of course, the OS has to know it's not supposed to touch certain hardware until after the BIOS is done initializing it and testing it. And so, there should be BIOS APIs to allow the OS to ask about this and get events as BIOS operations conclude. The OS, until given ownership of the screen, would output its status updates to the screen via a BIOS call. In fact, it would do that with all hardware, though the screen, keyboard and primary hard disk are the main items. When I say the OS, I actually mean both the bootloader that loads the OS and the OS itself once it is handed off to.

Next, the BIOS should, as soon as it has identified that the primary boot hard disks are ready, begin transferring data from the boot area into RAM. Almost all machines have far more RAM than they need to boot, and so pre-loading all blocks needed for boot into a cache, done in optimal order, will mean that by the time the OS kernal takes over, many of the disk blocks it will want to read will already be sitting in ram. Ideally, as I noted, the blocks should have been pre-stored in contiguous zones on the disk by an algorithm that watched the prior boots to see what was accessed and when.

Indeed, if there are multiple drives, the pre-loader could be configured to read from all of them, in a striping approach. Done properly, a freshly booted computer, once the drives had spun up, would start reading the few hundred megabytes of files it needs to boot from multiple drives into ram. All of this should be doable in just a few seconds on RAID style machines, where 3 disks striped can deliver 200mb/second or more of disk read performance. But even on a single drive, it should be quick. It would begin with the OS kernel and boot files, but then pre-cache all the pages from files used in typical boots. For any special new files, only a few seeks will be required after this is done. The OS and bootloader would of course need to know how to ask the BIOS for information on this cache, what blocks it holds and what's being loaded. They might even alter what it does. Ideally they would pre-store instructions to the BIOS about what they want it to do. Truth is, most OSs don't seem to get too involved with their hardware until a dozen or more seconds into their boot. A well designed booting system might even be set up to understand that different hardware becomes available at different times, and if there is not a required dependency order, it could deal with adding drivers and initializing hardware as it becomes available. Smart OSs are already trying to parallelize the various starting tasks, and this can continue. If the files are cached in ram, this parallelization will actually get much more efficient without the disk needing to thrash.

It's also the case that the boot must be fully abortable until instructed otherwise by the BIOS. That's because the BIOS may report that the user has decided to abort the boot or do configuration, even several seconds into the booting process. Most OSs don't do anything permanent for the beginning of their boot phase anyway. To extend this, a variant of filesystem snapshotting could be used, so that whatever disk writes the OS does during boot can be instantly backed-off if the boot is aborted. (A few safely done updates may make sense to log the boot process itself.)

Indeed, this is a good idea for all devices. I really get annoyed at the devices I have which I can start booting by accident (such as phones with a touchy power button) which then leave me trapped in a boot process I can't abort. They force me to watch the boot, then order a shutdown. Because most OSs don't do anything major on boot, sometimes I just pull the plug.

Of course, if there is flash disk available, it can make sense to use it. While I presume a system with flash disk might have other uses for it while running, if spare blocks hold data desired on boot, that should be known and used. As flash becomes cheaper some users may wish to always allocate a few hundred megs of it for storing what's needed for fast booting. This could also be written out to any cache flash on system shutdown, if you're not doing an immediate reboot. It also makes sense since flash drives are different drives to be pre-reading from both disk and flash for the maximum possible throughput.

As noted, with one processor this becomes a little more complex. We don't want to have to build a complete multitasking OS into th e BIOS or bootloader. However, there are simple forms of multitasking which can be made to work. One example is multitasking which requires each task to do an explicit handoff call saying that they are willing to wait for the other tools to get use of the processor for a while. Some sort of handoff mechanism is needed even with dual core, as both tasks must understand not to step on the other one since it is unlikely at this point that memory management or permissions would be in place. But this is not too hard. What the BIOS and bootloader do is simple and easy to coordinate with.

One could go even further, and add another layer. Some computers now have a "mini-OS" in the BIOS, which can do simple things like web browse. This mini-OS is there as a reaction to the horrible boot times of the major OSs. It's not out of the question to also have a mini-OS load and run in parallel with the booting of the main OS. A user could turn on their computer, and see a browser and fetch a web page or e-mail, but 20 seconds later, the main OS would take over, and have its own browser loaded, sucking a copy of the state from the mini-OS if the user did anything, so the mini-browser becomes a window in the fully booted OS when ready. However, first things first. I don't see why we can't have even a full Linux booting in well under 10 seconds on a fast computer.

Multiple boot devices

This idea could be extended to deal with the concept of multiple boot devices. Many computers are configured to try to boot first from CD-ROM and then from hard disk. In fact, the system could be reading and caching from all boot devices at once, as they come online. This could mean that the computer begins its non-destructive, reversible boot process from a flash drive or hard disk, and then aborts it when it sees there is a bootable OS on the cd-rom a few seconds later. And then possibly aborts that when the user hits a key saying they want to configure the BIOS. The goal is to never wait if there is something that can be done that might be useful, even if that will be thrown away.

It's even possible that the BIOS could support calls to do things with devices that are not even available yet. For example, a BIOS could contain a call to display information to the screen which just buffers the output until the screen is initialized.