Subject: Re: Kernel hot-swap using Kexec, BProc and CC/SMP Clusters.
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>
In-Reply-To: <m1d6ixb8m7.fsf@frodo.biederman.org>
References: <1052140733.2163.93.camel@spc9.esa.lanl.gov>
	 <m1d6ixb8m7.fsf@frodo.biederman.org>
Content-Type: text/plain
Organization: 
Message-Id: <1052157615.2163.113.camel@spc9.esa.lanl.gov>
Mime-Version: 1.0
Date: 05 May 2003 12:00:15 -0600
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1520
Lines: 39

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.
> 
> 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.
> 
> Thank you for the perspective.  This looks like I line I can
> sell to get some official time to work on kexec and it's friends
> more actively.

Cutting boot time in half is pretty good as it is right now.

> 
> >From what I have seen process migration/process check-pointing is
> currently the very rough area.
> 
> The interesting thing becomes how do you measure system uptime.
> 
> Eric

Perhaps two uptimes could be kept. The current concept of uptime would
remain as is, analogous to the reign of a king (the current kernel), and
a new integrated uptime would be analogous to the life of a dynasty. The
dynasty uptime would be one of the many things the new kernel learned
about on booting. This new dynasty uptime could become quite long if
everything keeps on ticking.

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/