[RFC] a prototype checkpoint-restart using core files

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Mon, Nov 07, 2005 at 07:57:25PM +0100, Mark Kettenis wrote:
> 
>>Heh, I'd expected Eli to ask for documentation ;-)
>>
>>Anyway, in this cause I think that's important since I expect a lot of
>>users won't understand its limitations.
>>
>>If I read the code correctly, there is one rather serious limitation
>>though: restoring mmapped area's will fail if the same area isn't
>>mapped in the target process.  Especially on systems that randomize
>>the location of mmapped memory this will make the usefullness of this
>>feature pretty limited :(.
> 
> 
> Why should it?  The expected use is to restore these dumps into the
> same running session - just after stepping a bit.  So unless you step
> across a very large free(), it should be fine.
> 
> I admit the general-purpose rcore command has a lot of limitations, but
> not as part of a checkpoint-restart system.

Yes, the next interesting task (before publication, I should think)
is to characterize and refine those limitations.  Experimentally,
I have found that I can jump backward across many system calls,
but not all.  I'd like to work on some idea of which ones are
always ok, which ones are sometimes ok, and which ones will never
be ok.

For instance, I wrote a simple test program that copies stdin
to stdout, one byte at a time, in a loop.  I ran it with input
and output redirected (so that it copies a file).  I checkpointed
it near the beginning, let it run thru 20,000 loops, then went
back to the checkpoint -- and then ran it to completion (so that
the first 20,000 bytes were copied twice).  The resulting input
and output files compared identical.

But when i repeated the experiment, but jumped backward across
50,000 loops, the output file was corrupted.

This is just a crude shot-in-the-dark experiment, obviously;
but it tends to show that we can get away with somewhat more
than we might at first suppose.

[this was ix86-linux native]