[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