From: Pavel Machek <pavel@suse.cz>
To: Rob Landley <landley@trommello.org>
Cc: zaimi@pegasus.rutgers.edu, linux-kernel@vger.kernel.org
Subject: Re: kernel upgrade on the fly
Date: Sat, 22 Jun 2002 10:34:11 +0200 [thread overview]
Message-ID: <20020622083411.GF102@elf.ucw.cz> (raw)
In-Reply-To: <20020619010945.6725B7D9@merlin.webofficenow.com>
Hi!
> Nothing is impossible for anyone impervious to reason, and you might suprise
> us (it'd make a heck of a graduate project). Hot migration isn't IMPOSSIBLE,
> it's just a flipping pain in the ass. But the issue's a bit threadbare in
> these parts (somewhere between "are we there yet mommy?" and "can I buy a
> pony?").
Actually, getting a pony is easy compared to *this* ;-).
> The SANE answer always has been to just schedule some down time for the box.
> The insane answer involves giving an awful lot of money to Sun or IBM or some
> such for hot-pluggable backplanes. (How do you swap out THE BACKPLANE?
> That's an answer nobody seems to have...)
You have two back backplanes and you use the other one during the switch?
> Clusters. Migrating tasks in the cluster, potentially similar problem. Look
> at mosix and the NUMA stuff as well, if you're actually serious
> about this.
> You have to reduce a process to its vital data, once all the resources you
> can peel away from it have been peeled away, swapped out, freed, etc. If you
> can suspend and save an individual running process to a disk image (just a
> file in the filesystem), in such a way that it can be individually re-loaded
> later (by the same kernel), you're halfway there. No, it's not as easy as it
> sounds. :)
Actually, if you can select few "important" processes, and only care
about them, it can be done from userspace. Martin Mares did something
like that, involving ptrace() and lots of limitations.
> > I can see the advantage of such a thing when a server can have the kernel
> > upgraded (major or minor upgrade) without disrupting the ongoing services
> > (ok, maybe a small few-seconds delay). Another instance would be to
> > switch between different kernels in the /boot/ directory (for testing
> > purposes, etc.) without rebooting the machine.
>
> See "belling the cat". Yeah, it's a great idea. The implementation's the
> tricky bit.
My dictionary is too weak for this.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
next prev parent reply other threads:[~2002-06-24 14:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-18 21:21 kernel upgrade on the fly zaimi
2002-06-18 19:37 ` Rob Landley
2002-06-19 5:09 ` Michael S. Zick
2002-06-19 17:22 ` John Alvord
2002-06-19 16:56 ` Rob Landley
2002-06-22 8:40 ` Pavel Machek
2002-06-22 8:34 ` Pavel Machek [this message]
2002-06-18 21:30 ` Russell King
-- strict thread matches above, loose matches on Subject: below --
2002-06-20 20:19 zaimi
2002-06-21 13:42 ` Rob Landley
2002-06-20 20:40 Jesse Pollard
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=20020622083411.GF102@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=landley@trommello.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zaimi@pegasus.rutgers.edu \
/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