From: Oren Laadan <orenl@cs.columbia.edu>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>,
jeremy@goop.org, arnd@arndb.de,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-mm@kvack.org, Alexander Viro <viro@zeniv.linux.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Andrey Mirkin <major@openvz.org>
Subject: Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart
Date: Thu, 16 Oct 2008 09:49:40 -0400 [thread overview]
Message-ID: <48F74674.20202@cs.columbia.edu> (raw)
In-Reply-To: <48F7352F.3020700@fr.ibm.com>
Daniel Lezcano wrote:
> Oren Laadan wrote:
>> Cedric Le Goater wrote:
>>> Dave Hansen wrote:
>>>> On Mon, 2008-10-13 at 10:13 +0200, Cedric Le Goater wrote:
>>>>> 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 ?
>>>> Do we ever have to worry about the kernel stack if we simply say that
>>>> tasks have to be *in* userspace when we checkpoint them.
>>> at a syscall boundary for example. that would make our life easier
>>> definitely.
>>
>> The ideal situation is never worry about kernel stack: either we catch
>> the task in user space or at a syscall boundary. This is taken care of
>> by freezing the tasks prior to checkpoint.
>>
>> The one exception (and it is a tedious one !) are states in which the
>> task is already frozen by definition: any ptrace blocking point where
>> the tracee waits for the tracer to grant permission to proceed with
>> its execution. Another example is in vfork(), waiting for completion.
>
> I would say these are perfect places for "may be non-checkpointable" :)
For now, yes. But we definitely want this capability in the long
run; otherwise we won't be able to checkpoint a kernel compile
('make' uses vfork), or anything with 'gdb' running inside, or
'strace', and other goodies.
>
>> In both cases, there will be a kernel stack and we cannot avoid it.
>> The bad news is that it may be a bit tedious to restart these cases.
>> The good news, however, is that they are very well defined locations
>> with well defined semantics. So upon restart all that is needed is
>> to emulate the expected behavior had we not been checkpointed. This,
>> luckily, does not require rebuilding the kernel stack, but instead
>> some smart glue code for a finite set of special cases.
WARNING: multiple messages have this Message-ID (diff)
From: Oren Laadan <orenl@cs.columbia.edu>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>,
jeremy@goop.org, arnd@arndb.de,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-mm@kvack.org, Alexander Viro <viro@zeniv.linux.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Andrey Mirkin <major@openvz.org>
Subject: Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart
Date: Thu, 16 Oct 2008 09:49:40 -0400 [thread overview]
Message-ID: <48F74674.20202@cs.columbia.edu> (raw)
In-Reply-To: <48F7352F.3020700@fr.ibm.com>
Daniel Lezcano wrote:
> Oren Laadan wrote:
>> Cedric Le Goater wrote:
>>> Dave Hansen wrote:
>>>> On Mon, 2008-10-13 at 10:13 +0200, Cedric Le Goater wrote:
>>>>> 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 ?
>>>> Do we ever have to worry about the kernel stack if we simply say that
>>>> tasks have to be *in* userspace when we checkpoint them.
>>> at a syscall boundary for example. that would make our life easier
>>> definitely.
>>
>> The ideal situation is never worry about kernel stack: either we catch
>> the task in user space or at a syscall boundary. This is taken care of
>> by freezing the tasks prior to checkpoint.
>>
>> The one exception (and it is a tedious one !) are states in which the
>> task is already frozen by definition: any ptrace blocking point where
>> the tracee waits for the tracer to grant permission to proceed with
>> its execution. Another example is in vfork(), waiting for completion.
>
> I would say these are perfect places for "may be non-checkpointable" :)
For now, yes. But we definitely want this capability in the long
run; otherwise we won't be able to checkpoint a kernel compile
('make' uses vfork), or anything with 'gdb' running inside, or
'strace', and other goodies.
>
>> In both cases, there will be a kernel stack and we cannot avoid it.
>> The bad news is that it may be a bit tedious to restart these cases.
>> The good news, however, is that they are very well defined locations
>> with well defined semantics. So upon restart all that is needed is
>> to emulate the expected behavior had we not been checkpointed. This,
>> luckily, does not require rebuilding the kernel stack, but instead
>> some smart glue code for a finite set of special cases.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-10-16 13:52 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 10:19 [RFC v6][PATCH 0/9] Kernel based checkpoint/restart Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 1/9] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 2/9] General infrastructure for checkpoint restart Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 3/9] x86 support for checkpoint/restart Oren Laadan
2008-10-08 10:19 ` Oren Laadan
[not found] ` <1223461197-11513-4-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-10 10:21 ` Cedric Le Goater
2008-10-10 10:21 ` Cedric Le Goater
2008-10-10 10:21 ` Cedric Le Goater
[not found] ` <48EF2CB3.9040900-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-10 10:24 ` Oren Laadan
2008-10-10 10:24 ` Oren Laadan
2008-10-10 10:24 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 4/9] Dump memory address space Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 5/9] Restore " Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 15:35 ` Dave Hansen
2008-10-08 15:35 ` Dave Hansen
[not found] ` <1223461197-11513-6-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-08 15:35 ` Dave Hansen
[not found] ` <1223461197-11513-1-git-send-email-orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-08 10:19 ` [RFC v6][PATCH 1/9] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 2/9] General infrastructure for checkpoint restart Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 3/9] x86 support for checkpoint/restart Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 4/9] Dump memory address space Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 5/9] Restore " Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 6/9] Checkpoint/restart: initial documentation Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 7/9] Infrastructure for shared objects Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 8/9] Dump open file descriptors Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 9/9] Restore open file descriprtors Oren Laadan
2008-10-09 12:46 ` [RFC v6][PATCH 0/9] Kernel based checkpoint/restart Ingo Molnar
2008-10-08 10:19 ` [RFC v6][PATCH 6/9] Checkpoint/restart: initial documentation Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 7/9] Infrastructure for shared objects Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 8/9] Dump open file descriptors Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-08 10:19 ` [RFC v6][PATCH 9/9] Restore open file descriprtors Oren Laadan
2008-10-08 10:19 ` Oren Laadan
2008-10-09 12:46 ` [RFC v6][PATCH 0/9] Kernel based checkpoint/restart Ingo Molnar
2008-10-09 12:46 ` Ingo Molnar
[not found] ` <20081009124658.GE2952-X9Un+BFzKDI@public.gmane.org>
2008-10-09 12:58 ` Dave Hansen
2008-10-09 12:58 ` Dave Hansen
2008-10-09 12:58 ` Dave Hansen
2008-10-09 13:17 ` Ingo Molnar
2008-10-09 13:17 ` Ingo Molnar
2008-10-09 13:34 ` Dave Hansen
2008-10-09 13:34 ` Dave Hansen
2008-10-09 13:44 ` Ingo Molnar
2008-10-09 13:44 ` Ingo Molnar
2008-10-09 13:44 ` Ingo Molnar
2008-10-09 16:50 ` Dave Hansen
2008-10-09 16:50 ` Dave Hansen
2008-10-10 15:39 ` Ingo Molnar
2008-10-10 15:39 ` Ingo Molnar
2008-10-10 15:39 ` Ingo Molnar
[not found] ` <20081010153951.GD28977-X9Un+BFzKDI@public.gmane.org>
2008-10-13 8:13 ` Cedric Le Goater
2008-10-13 8:13 ` Cedric Le Goater
2008-10-13 8:13 ` Cedric Le Goater
2008-10-13 16:12 ` Oren Laadan
2008-10-13 16:12 ` Oren Laadan
2008-10-15 15:13 ` Cedric Le Goater
2008-10-15 15:13 ` Cedric Le Goater
2008-10-15 23:59 ` Oren Laadan
2008-10-15 23:59 ` Oren Laadan
[not found] ` <48F60891.1070807-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-15 23:59 ` Oren Laadan
[not found] ` <48F3737B.6070904-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-15 15:13 ` Cedric Le Goater
[not found] ` <48F30315.1070909-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-13 16:12 ` Oren Laadan
2008-10-13 16:43 ` Dave Hansen
2008-10-13 16:43 ` Dave Hansen
2008-10-13 16:43 ` Dave Hansen
2008-10-15 15:15 ` Cedric Le Goater
2008-10-15 15:15 ` Cedric Le Goater
[not found] ` <48F6092D.6050400-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-16 0:06 ` Oren Laadan
2008-10-16 0:06 ` Oren Laadan
2008-10-16 0:06 ` Oren Laadan
[not found] ` <48F685A3.1060804-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-16 12:35 ` Daniel Lezcano
2008-10-16 12:35 ` Daniel Lezcano
2008-10-16 12:35 ` Daniel Lezcano
[not found] ` <48F7352F.3020700-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-16 13:49 ` Oren Laadan
2008-10-16 13:49 ` Oren Laadan [this message]
2008-10-16 13:49 ` Oren Laadan
2008-10-16 22:51 ` Peter Chubb
2008-10-16 22:51 ` Peter Chubb
2008-10-17 6:30 ` David Newall
2008-10-17 6:30 ` David Newall
[not found] ` <48F83121.7070705-KzQzY1MbaKjAHznzqCTclw@public.gmane.org>
2008-10-20 17:17 ` Dave Hansen
2008-10-20 17:17 ` Dave Hansen
2008-10-20 17:17 ` Dave Hansen
2008-10-17 6:44 ` Cedric Le Goater
2008-10-17 6:44 ` Cedric Le Goater
2008-10-17 7:08 ` Oren Laadan
2008-10-17 7:08 ` Oren Laadan
[not found] ` <87r66g8875.wl%peter-LkDQP0DxSMGxwJ88Py/mJxCuuivNXqWP@public.gmane.org>
2008-10-17 6:30 ` David Newall
2008-10-17 6:44 ` Cedric Le Goater
2008-10-17 7:08 ` Oren Laadan
[not found] ` <48F74674.20202-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-16 22:51 ` Peter Chubb
2008-10-15 15:15 ` Cedric Le Goater
[not found] ` <20081009134415.GA12135-X9Un+BFzKDI@public.gmane.org>
2008-10-09 16:50 ` Dave Hansen
2008-10-09 21:59 ` Greg Kurz
2008-10-09 21:59 ` Greg Kurz
[not found] ` <20081009131701.GA21112-X9Un+BFzKDI@public.gmane.org>
2008-10-09 13:34 ` Dave Hansen
2008-10-09 21:59 ` Greg Kurz
2008-10-09 13:17 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2008-10-08 10:19 Oren Laadan
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=48F74674.20202@cs.columbia.edu \
--to=orenl@cs.columbia.edu \
--cc=arnd@arndb.de \
--cc=clg@fr.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=dlezcano@fr.ibm.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=major@openvz.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.