Star Linux: Reboot Like a Racecar with kexec
Linked by Thom Holwerda on Thu 16th Oct 2008 22:08 UTC, submitted by diegocg
Linux Kexec is a feature that allows to boot kernels from a working kernel. It was originally intended for use by kernel and system developers who had to reboot several times a day. Soon, system administrators for high-availability servers found use for it as well. As systems get more and more advanced, and boot times get longer, end users can now benefit from it.
E-mail Print r 6   29 Comment(s) http://osne.ws/fqm
Thread beginning with comment 334035
To read all comments associated with this story, please click here.
Just skips the BIOS POST, right?
by Morph on Fri 17th Oct 2008 00:03 UTC
Morph
Member since:
2007-08-20

That's the big speedup; the actual kernel initialisation time isn't any faster when rebooting with kexec, right?

Reply Bookmark Score: 1

TemporalBeing Member since:
2007-08-22

That's the big speedup; the actual kernel initialisation time isn't any faster when rebooting with kexec, right?


Not sure how Linux does it - haven't looked at the source at all - but it could theoretically be faster than a normal boot operation. How?

Well, basically the various parts of the system would have to load the new kernel, temporarily halt (perhaps the processors System-Maintenance Mode?), serialize the states of everything in a special manner, start the new kernel with the serialized data, the deserialize everything and continue. You don't even have to necessarily stop all the hardware - just pause the I/O between the serialization/deserialization steps.

So while boot may take 5 seconds - and you have to go through POST, do all kinds of initialization, etc. - kexec() style rebooting could very well be under 1 second since you skip the whole POST step, and you can even skip most of the initialization steps if you serialize/deserialize correctly.

Of course, you have to have two kernels that understand the same serialization structures. So it would have to be versioned and you would have to have some way to fall back to the old kernel in case the new one had a problem in the deserialization.

Reply Parent Bookmark Score: 1

Morin Member since:
2005-12-31

> Of course, you have to have two kernels that understand the same
> serialization structures. So it would have to be versioned and you would
> have to have some way to fall back to the old kernel in case the new
> one had a problem in the deserialization.

I think that kinda defeats the purpose. Exchanging kernels is a risky task anyway, and introducing yet another potential source of problems (like the de-/serialization you mentioned) doesn't seem very wise to me. Especially if your goal is either kernel development or a high-availability system.

Reply Parent Bookmark Score: 2

Morph Member since:
2007-08-20

serialize the states of everything in a special manner

Yes, possible in theory, but sounds very difficult. Every driver would need to be modified to support it, and for some hardware (eg video cards, which undergo lots of voodoo-magic during video BIOS initialisation) there might be subtle caveats. Sounds like a lot of effort!
Anyway, hopefully in a couple of years EFI will replace BIOS, and slow POSTs will be a relic of the past.

Reply Parent Bookmark Score: 1