How much do you cache? Hardware is difficult because you could add/remove/swap it at any time, and software information is already partly cached depending on your OS.

IIRC, Windows a) builds a list of files to pre-load from disk based on your usage, and b) doesn't actually fully shut down by default (it goes to hibernate mode: http://blogs.msdn.com/b/olivnie/archive/2012/12/14/windows-8...). I don't know if any Linux distros do either of those by default, but it is certainly possible.

Also, some BIOSes already have a "quick boot" setting which caches some hardware information, particularly about memory. It usually comes with a warning that you need to disable the setting for at least one boot when installing RAM.

But an embedded system wouldn't change between two reboots.

Hardware requires specific handshaking to get it to initialize, the kernel cannot assume that the hardware that was present last time is available this time, and orchestrating everything is not an easy process.

The holy grail would be a kernel organized and designed to cache everything to disk related to its own configuration, and only re-execute/rerun the hardware reinitialization code.

Admittedly, Windows' current approach to bootup is very close: it closes all applications then pseudo-hibernates the kernel. Bootup simply reads the hibernated kernel state from disk and reloads userspace.

This is of course besides traditional full ACPI hibernation, which is pretty cool but isn't a perfect art. (I'm typing this on a ThinkPad T23, a fairly old (and thus well-tested) hardware configuration; its hibernation/resume is usually rock-solid, but this morning my WLAN decided to get all stupid with dhcpcd, and USB decided that while it could see my external HDD, there wasn't a disk inside it. From-scratch boot is still the only way to get a reasonably predictable system state.)

The biggest problem with caching things during the boot process is that turning our devices off and on again will not magically solve our problems any more.

That's why there's always a seperate reboot option which tells the fairy to do her job.

I think you'll find that boot time is entirely dominated by time waiting for hardware devices to do various things rather than CPU bound.

Also known as "suspend to disk"?

After which you'd have to load 8Gb from disk/SSD in under 1 second...

No, you don't. You need to load kernel space, and then demand page in the rest as it's being accessed.

I wonder if there are any disk suspend systems that are smart enough to tie into the VM system... instead of a specific monolithic RAM-sized suspend file, just flush everything to virtual memory on suspend, and on awake only restore the minimum needed for the OS and accounting, then start swapping everything else in lazily as the user needs it (or in advance in the background if the user is idle)

Given that the disk is several orders of magnitude slower that the RAM, lazily re-loading pages from the disk to the memory can induce very visible and annoying loading delays everywhere (e.g. change tab in browser takes 3 sec).

I'd rather wait 10 extra second than having a slow computer for the next 10 minutes.

Or you could go for the hybrid, of having 10 seconds of reduced performance while the system keeps aggressively loading pages.

Linux does approximately this.

If you need 8G of resident memory to have the apps you want running then you need 8G... no shortcuts. That is a pretty high figure, though. Afaik things like disk caches aren't restored during a suspend/resume.

Maybe something has changed since last boot.

In the embedded hardware environment if something has changed and if this change is out of specs, then what you say can be adopted.

Isn't that what hibernate / suspend / hybrid sleep is?