[RFC v6][PATCH 0/9] Kernel based checkpoint/restart
Cedric Le Goater
clg at fr.ibm.com
Mon Oct 13 01:13:09 PDT 2008
Ingo Molnar wrote:
> * Dave Hansen <dave at linux.vnet.ibm.com> wrote:
>
>> On Thu, 2008-10-09 at 15:44 +0200, Ingo Molnar wrote:
>>> there might be races as well, especially with proxy state - and
>>> current->flags updates are not serialized.
>>>
>>> So maybe it should be a completely separate flag after all? Stick it
>>> into the end of task_struct perhaps.
>> What do you mean by proxy state? nsproxy?
>
> it's a concept: one task installing some state into another task (which
> state must be restored after a checkpoint event), while that other task
> is running. Such as a pi-futex state for example.
>
> So a task can acquire state not just by its own doing, but via some
> other task too.
thinking aloud,
hmm, that's rather complex, because we have to take into account the
kernel stack, no ? This is what Andrey was trying to solve in his patchset
back in September :
http://lkml.org/lkml/2008/9/3/96
the restart phase simulates a clone and switch_to to (not) restore the kernel
stack. right ?
the self checkpoint and self restore syscalls, like Oren is proposing, are
simpler but they require the process cooperation to be triggered. we could
image doing that in a special signal handler which would allow us to jump
in the right task context.
I don't have any preference but looking at the code of the different patchsets
there are some tricky areas and I'm wondering which path is easier, safer,
and portable.
C.
More information about the Containers
mailing list