public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Scott Lovenberg <scott.lovenberg@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: RFC: Self-snapshotting in Linux
Date: Wed, 16 Apr 2008 06:33:05 -0400	[thread overview]
Message-ID: <4805D5E1.1070906@gmail.com> (raw)
In-Reply-To: <804dabb00804160144j25584229t6673bc182fa13b3@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3501 bytes --]

Peter Teoh wrote:
> Sorry if this is a a crazy idea.....just be forewarned....
>
> First, I would like to make a reference to VMWare's snapshot (name not
> important, emphasize the idea) feature - hopefully u are familiar with
> it.   This is a feature whereby u can freeze the entire OS (kernel +
> userspace application running) and then later reload itself next time,
> continuing where it left off, without reboot from ground zero.
>
> Next, can I ask, is such a feature useful in Linux?   Ie, able to
> restart the kernel + userspace application from where u left off, the
> last time round.    Not JUST the normal suspend/resume feature, but
> more important able to CHOOSE among the different available images for
> u to resume on.   Eg, u want to freeze the current 2.6.25-rc6 kernel,
> save it, and then restore back the 2.6.23-rc5 image, work on it, save
> it, and then restore the previous image again.   All done without
> virtualization as in the VMWare sense - which really is CPU intensive
> and slow things  down a lot.   Now we can directly execute each OS
> kernel image on the CPU, and since saving and restoring is quite fast
> (eg, zipping up the entire physical memory before saving into
> permanent storage) - I supposed this will be much faster than the
> normal initialization/fsck work done normally....or did I missed out
> anything?
>
> Essentially, to reiterate the key idea:   able to snapshot the current
> kernel+userspace permanent.....restore from another snapshot....and
> then switch back again if needed etc.....will the implementation be
> difficult...if not impossible????
>
>   
Hrm... well, the kernel has the ability since 2.6.20 (although its in 
testing AFAIK) to relocate itself on a crash.  Reference:


      Relocatable kernel support for x86

This feature (enabled with CONFIG_RELOCATABLE) isn't very noticeable for 
end-users but it's quite interesting from a kernel POV. Until now, it 
was a requirement that a i386 kernel was loaded at a fixed memory 
address in order to work, loading it in a different place wouldn't work. 
This feature allows to compile a kernel that can be loaded at different 
4K-aligned addresses, but always below 1 GB, with no runtime overhead. 
Kdump users (a feature introduced in 2.6.13 
<http://kernelnewbies.org/Linux_2_6_13> that triggers kexec 
<http://lwn.net/Articles/108595/> in a kernel crash in order to boot a 
kernel that has been previously loaded at an 'empty' address, then runs 
that kernel, saves the memory where the crashed kernel was placed, dumps 
it in a file and continues booting the system) will benefit from this 
because until now the "rescue kernel" needed to be compiled with 
different configuration options in order to make it bootable at a 
different address. With a relocatable kernel, the same kernel can be 
booted at different addresses. (commit 1 
<http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=968de4f02621db35b8ae5239c8cfc6664fb872d8>, 
2 
<http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e69f202d0a1419219198566e1c22218a5c71a9a6>, 
3 
<http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=be274eeaf20b4c7155242645d5e2c48b023e609b>, 
4) 
<http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fd593d12770d4a0d1ff095d44b96436c18479ee8>



Maybe you load up another kernel to handle the snapshot, and then hand 
the system back to it afterwards?  What do you think?

[-- Attachment #2: scott_lovenberg.vcf --]
[-- Type: text/x-vcard, Size: 525 bytes --]

begin:vcard
fn:Scott Lovenberg
n:Lovenberg;Scott
org:The CleftStone Works
adr:;;;Kutztown;PA;19530;USA
email;internet:scott.lovenberg@gmail.com
tel;cell:570-856-2999
note;quoted-printable:Interests:=0D=0A=
	Programming, *NIX, Slackware, Samba, C/C++, Perl, Java, .NET, Kernel Hack=
	ing, Virtual Machines, FOSS, Security, Operating Systems, Various Softwar=
	e Stacks.  =
	=0D=0A=
	=0D=0A=
	Always have time for "shop talk"; feel free to drop me a line.
x-mozilla-html:TRUE
url:www.cleftstoneworks.com
version:2.1
end:vcard


  parent reply	other threads:[~2008-04-16 10:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16  8:44 RFC: Self-snapshotting in Linux Peter Teoh
2008-04-16  8:49 ` eric miao
2008-04-16  9:49 ` Ben Nizette
2008-04-16 10:33 ` Scott Lovenberg [this message]
2008-04-16 11:14 ` Pavel Machek
     [not found]   ` <804dabb00804160821n4872c65fh44f2c07ead67fc49@mail.gmail.com>
2008-04-17  9:33     ` Pavel Machek
2008-04-16 18:31 ` Greg Freemyer
     [not found] <ajbvb-3Ur-21@gated-at.bofh.it>
     [not found] ` <ajcri-65w-13@gated-at.bofh.it>
2008-04-16 10:27   ` Alan Jenkins
2008-04-16 11:12     ` Pavel Machek
2008-04-16 13:50       ` Alan Jenkins
2008-04-17  9:32         ` Pavel Machek
2008-04-19 16:42           ` Alan Jenkins
2008-04-17  0:55     ` Nigel Cunningham
2008-04-17  7:48       ` Alan Jenkins
     [not found] ` <ajd42-7Gt-49@gated-at.bofh.it>
2008-04-16 11:02   ` Alan Jenkins
2008-04-16 15:06     ` Peter Teoh
2008-04-16 16:21       ` Disconnect
2008-04-16 19:50       ` Vivek Goyal
     [not found]         ` <48065C64.7010808@gmail.com>
2008-04-16 20:10           ` Scott Lovenberg
2008-04-16 20:25           ` Vivek Goyal
2008-04-17  2:09             ` Scott Lovenberg
2008-04-17  6:23           ` Peter Teoh
2008-04-17  8:43             ` Alan Jenkins
2008-04-17 16:01               ` Scott Lovenberg

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=4805D5E1.1070906@gmail.com \
    --to=scott.lovenberg@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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