From: Steven Cole <elenstev@mesatop.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, Larry McVoy <lm@bitmover.com>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Kernel hot-swap using Kexec, BProc and CC/SMP Clusters.
Date: 05 May 2003 19:28:42 -0600 [thread overview]
Message-ID: <1052184521.9059.660.camel@spc> (raw)
In-Reply-To: <m1d6ixb8m7.fsf@frodo.biederman.org>
On Mon, 2003-05-05 at 11:34, Eric W. Biederman wrote:
> So summarize:
> 1) Run multiple kernels (minimally kernels A and B)
> 2) Migrate processes from kernel A to kernel B
> 3) Use kexec to replace kernel A once all processes have left.
> 4) Repeat for all other kernels.
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
next prev parent reply other threads:[~2003-05-06 1:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-05 13:18 Kernel hot-swap using Kexec, BProc and CC/SMP Clusters Steven Cole
2003-05-05 14:22 ` Karim Yaghmour
2003-05-05 17:34 ` Eric W. Biederman
2003-05-05 18:00 ` Steven Cole
2003-05-05 18:17 ` Valdis.Kletnieks
2003-05-05 19:51 ` Steven Cole
2003-05-05 20:25 ` Richard B. Johnson
2003-05-05 18:16 ` Chris Friesen
2003-05-06 1:28 ` Steven Cole [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-05-06 3:19 Stephen M. Kenton
2003-05-06 9:49 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1052184521.9059.660.camel@spc \
--to=elenstev@mesatop.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox