Serge E. Hallyn wrote:Quoting Daniel Lezcano (dlezcano@xxxxxxxxxx):Oren Laadan wrote:Right, Oren, iiuc you are insisting that 'external checkpoint' andDaniel Lezcano wrote:Yep, I read your patchset :)Louis Rilling wrote:This is a misconception: my patches are not "internal checkpoint". MyOn Fri, Oct 17, 2008 at 04:33:03PM -0700, Dave Hansen wrote:I agree with Louis.On Wed, 2008-09-03 at 14:57 +0400, Andrey Mirkin wrote:To be fair, and since (IIRC) the initial intent was to start with OpenVZ'sThis patchset introduces kernel based checkpointing/restart as it isHi Andrey,
implemented in OpenVZ project. This patchset has limited functionality and
are able to checkpoint/restart only single process. Recently Oren Laaden
sent another kernel based implementation of checkpoint/restart. The main
differences between this patchset and Oren's patchset are:
I'm curious what you want to happen with this patch set. Is there
something specific in Oren's set that deficient which you need
implemented? Are there some technical reasons you prefer this code?
approach, shouldn't Oren answer the same questions with respect to Andrey's
I'm afraid that we are forgetting to take the best from both approaches...
I played with Oren's patchset and tryed to port it on x86_64. I was able to sys_checkpoint/sys_restart but if you remove the restoring of the general registers, the restart still works. I am not an expert on asm, but my hypothesis is when we call sys_checkpoint the registers are saved on the stack by the syscall and when we restore the memory of the process, we restore the stack and the stacked registers are restored when exiting the sys_restart. That make me feel there is an important gap between external checkpoint and internal checkpoint.
patches are basically "external checkpoint" by design, which *also*
accommodates self-checkpointing (aka internal). The same holds for the
restart. The implementation is demonstrated with "self-checkpoint" to
avoid complicating things at this early stage of proof-of-concept.
I just want to clarify what we want to demonstrate with this patchset for the proof-of-concept ? A self CR does not show what are the complicate parts of the CR, we are just showing we can dump the memory from the kernel and do setcontext/getcontext.
We state at the container mini-summit on an approach:
2. Freeze the container
4. Thaw/Kill the container
We already have the freezer, and we can forget for now pre-dump and post-dump.
IMHO, for the proof-of-concept we should do a minimal CR (like you did), but conforming with these 5 points, but that means we have to do an external checkpoint.
'multiple task checkpoint' are the same thing. But they aren't.
Rather, I think that what we say is 'multiple tasks c/r' is what you say
should be done from user-space :)
Then I don't explain myself clearly :)
The only thing I consider doing in user space is the creation of
the container, the namespaces and the processes.
I argue that "external checkpoint of a single process" is very few
lines of code away from "self checkpoint" that is in v7.
I'm not sure how you define "external restart" ? eventually, the
processes restart themselves. It is a question of how the processes
are created to begin with.
So particularly given that your patchset seems to be in good shape,
I'd like to see external checkpoint explicitly supported. Please
just call me a dunce if v7 already works for that.
It seems like you want a single process to checkpoint a single (other)
process, and then a single process to start a single (other) process.
I tried to explicitly avoid dealing with the container (user space ?
kernel space ?) and with creating new processes (user space ? kernel
Nevertheless, it's the _same_ code. All that is needed is to make the
checkpoint syscall refer to the other task instead of self, and the
restart should create a container and fork there, then call sys_restart.
I guess instead of repeating this argument over, I will go ahead and
post a patch on top of v7 to demonstrate this (without a container,
therefore without preserving the original pid).