Just a small correction to the summary. I was not assuming that
multiple kernels are running at the beginning So the summary is more
like:
1) Make hardware available and use kexec to boot kernel B.
2) Migrate processes from kernel A to kernel B.
3) Once all processes have left kernel A, kernel B takes over A's turf,
maybe with a really big kfree().
4) The end state is the same as the beginning, but with a new kernel.
For a machine already partitioned into clusters, your original summary
is correct.
> On two simple machines working in tandem (The most common variation
> used for high availability this should be easy to do). And it is
> preferable to a reboot because of the additional control and speed.
Doing this on separate machines would be a good warm-up to doing it on
one machine partitioned into CC clusters.
Here is a direct link to Karim's paper on CC clusters (html version):
http://www.opersys.com/adeos/practical-smp-clusters/
I had forgotten about the nanokernel approach when I made my original
post. If doing it this way is not everyone's cup of tea, there could be
other solutions.
Also, I've been assuming that processes to be moved would have their
dirty pages written out prior to migration. This should eliminate the
need for moving a lot of data structures around, which would probably be
difficult anyway since those structures could arbitrarily change from
one kernel version to the next.
Steven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/