Skip to contentSkip to conversation

Switching Kernels without Rebooting?

DISCUSSION David Balazic 4 participants 4 messages Jul 11, 2001

lore
Share & tools
lore
#0 lore raw
Quoted 12 lines · C. Slater

Hi, i was just thinking about if it would be possible to switch kernels without haveing to restart the entire system. Sort of a "Live kernel replacement". It sort of goes along with the hot-swap-everything ideas. I was thinking something like
- Take all the structs related to userspace memory and processes
- Save them to a reserved area of memory
- Halt the kernel, mostly
- Wipe kernel-space memory clean to avoid confusion
- Load new kernel into memory
- Replace all saved structures
- Start kernel running agin

Quoted 2 lines

This seems like the easiest way to do it. The biggest problem is that there would be somewhere about 30 seconds where all processes would be frozen.

This is not a problem at all, because UNIX does not guarantee that a process will get at least one CPU slice every X seconds. ( read : UNIX is not a real time system )

soft-suspend "freezes" processes for several hours anyway ...

Note that there is a patch for hot replacing a kernel, which is equivalent to rebooting, but much faster :
Two Kernel Monte (Linux loading Linux on x86)
http://www.scyld.com/products/beowulf/software/monte.html

Quoted 3 lines

This could cause problems with tcp/ip connections timeing out say on a webserver, but it would be more managable than a few minutes downtime to restart the machine.

[ rest snipped ]

Signature · 4 lines
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
#1 lore raw
Quoted 5 lines

This is not a problem at all, because UNIX does not guarantee that a process will get at least one CPU slice every X seconds. ( read : UNIX is not a real time system )

Quoted 7 lines

soft-suspend "freezes" processes for several hours anyway ...

Note that there is a patch for hot replacing a kernel, which is equivalent to rebooting, but much faster :
Two Kernel Monte (Linux loading Linux on x86)
http://www.scyld.com/products/beowulf/software/monte.html

So if the Two Kernel Monte patch was combined with the system suspend/resume in swap patch then you add some transitions so that the code path does this:

1-  Suspend->Monte
2-  Monte->Load new Kernel
3-  Load->Resume.

If it was just for very similar kernels, i.e. most -pre and -ac kernels it would probably work fine. If not, then you could just do the Monte route.

Laramie

#2 lore raw
In reply to David Balazic
Quoted 3 lines

This is not a problem at all, because UNIX does not guarantee that a process will get at least one CPU slice every X seconds. ( read : UNIX is not a real time system )

It is not a problem when a system is isolated from all other systems, but if we do this while some program is in a tcp/ip session, like a webserver, the program will not beable to respond to an outside computer for the time while we are swaping and initilizing kernels. The tcp connection will time out on the side of the other computer then. But this is still quite managable compared to a minute or 2 for a system to totaly reboot itself.

Quoted 1 line

soft-suspend "freezes" processes for several hours anyway ...

Yes, so it will not be a problem at least with processes dieing because they did not get message X at time Y.

#3 lore raw
In reply to David Balazic
Followup to:  <[email protected]>
By author:    "Laramie Leavitt" <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 5 lines

So if the Two Kernel Monte patch was combined with the system suspend/resume in swap patch then you add some transitions so that the code path does this:

Quoted 8 lines
1-  Suspend->Monte
2-  Monte->Load new Kernel
3-  Load->Resume.

If it was just for very similar kernels, i.e. most -pre and -ac kernels it would probably work fine. If not, then you could just do the Monte route.

The problem is that "freezing" the kernel state and then reconstructing it into a form USABLE BY ANOTHER KERNEL (not even necessarily another kernel version) is unbelievably hard; furthermore, it imposes a severe constrains about the kind of changes you're allowed to make during your kernel development.

It's a bad idea, folks. Give it up.

-hpa

Signature · 3 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt