public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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