From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart Date: Thu, 09 Oct 2008 05:58:42 -0700 Message-ID: <1223557122.11830.14.camel@nimitz> References: <1223461197-11513-1-git-send-email-orenl@cs.columbia.edu> <20081009124658.GE2952@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20081009124658.GE2952-X9Un+BFzKDI@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Ingo Molnar Cc: jeremy-TSDbQ3PG+2Y@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Alexander Viro , "H. Peter Anvin" List-Id: containers.vger.kernel.org On Thu, 2008-10-09 at 14:46 +0200, Ingo Molnar wrote: > * Oren Laadan wrote: > > > These patches implement basic checkpoint-restart [CR]. This version > > (v6) supports basic tasks with simple private memory, and open files > > (regular files and directories only). Changes mainly cleanups. See > > original announcements below. > > i'm wondering about the following productization aspect: it would be > very useful to applications and users if they knew whether it is safe to > checkpoint a given app. I.e. whether that app has any state that cannot > be stored/restored yet. Absolutely! My first inclination was to do this at checkpoint time: detect and tell users why an app or container can't actually be checkpointed. But, if I get you right, you're talking about something that happens more during the runtime of the app than during the checkpoint. This sounds like a wonderful approach to me, and much better than what I was thinking of. What kind of mechanism do you have in mind? int sys_remap_file_pages(...) { ... oh_crap_we_dont_support_this_yet(current); } Then the oh_crap..() function sets a task flag or something? -- Dave From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758939AbYJIM6z (ORCPT ); Thu, 9 Oct 2008 08:58:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756585AbYJIM6r (ORCPT ); Thu, 9 Oct 2008 08:58:47 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:46421 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754334AbYJIM6r (ORCPT ); Thu, 9 Oct 2008 08:58:47 -0400 Subject: Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart From: Dave Hansen To: Ingo Molnar Cc: Oren Laadan , jeremy@goop.org, arnd@arndb.de, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro , "H. Peter Anvin" In-Reply-To: <20081009124658.GE2952@elte.hu> References: <1223461197-11513-1-git-send-email-orenl@cs.columbia.edu> <20081009124658.GE2952@elte.hu> Content-Type: text/plain Date: Thu, 09 Oct 2008 05:58:42 -0700 Message-Id: <1223557122.11830.14.camel@nimitz> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2008-10-09 at 14:46 +0200, Ingo Molnar wrote: > * Oren Laadan wrote: > > > These patches implement basic checkpoint-restart [CR]. This version > > (v6) supports basic tasks with simple private memory, and open files > > (regular files and directories only). Changes mainly cleanups. See > > original announcements below. > > i'm wondering about the following productization aspect: it would be > very useful to applications and users if they knew whether it is safe to > checkpoint a given app. I.e. whether that app has any state that cannot > be stored/restored yet. Absolutely! My first inclination was to do this at checkpoint time: detect and tell users why an app or container can't actually be checkpointed. But, if I get you right, you're talking about something that happens more during the runtime of the app than during the checkpoint. This sounds like a wonderful approach to me, and much better than what I was thinking of. What kind of mechanism do you have in mind? int sys_remap_file_pages(...) { ... oh_crap_we_dont_support_this_yet(current); } Then the oh_crap..() function sets a task flag or something? -- Dave From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id m99CwESw030517 for ; Thu, 9 Oct 2008 06:58:14 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m99CwjAA183424 for ; Thu, 9 Oct 2008 06:58:45 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m99CwivQ005383 for ; Thu, 9 Oct 2008 06:58:45 -0600 Subject: Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart From: Dave Hansen In-Reply-To: <20081009124658.GE2952@elte.hu> References: <1223461197-11513-1-git-send-email-orenl@cs.columbia.edu> <20081009124658.GE2952@elte.hu> Content-Type: text/plain Date: Thu, 09 Oct 2008 05:58:42 -0700 Message-Id: <1223557122.11830.14.camel@nimitz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Ingo Molnar Cc: Oren Laadan , jeremy@goop.org, arnd@arndb.de, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro , "H. Peter Anvin" List-ID: On Thu, 2008-10-09 at 14:46 +0200, Ingo Molnar wrote: > * Oren Laadan wrote: > > > These patches implement basic checkpoint-restart [CR]. This version > > (v6) supports basic tasks with simple private memory, and open files > > (regular files and directories only). Changes mainly cleanups. See > > original announcements below. > > i'm wondering about the following productization aspect: it would be > very useful to applications and users if they knew whether it is safe to > checkpoint a given app. I.e. whether that app has any state that cannot > be stored/restored yet. Absolutely! My first inclination was to do this at checkpoint time: detect and tell users why an app or container can't actually be checkpointed. But, if I get you right, you're talking about something that happens more during the runtime of the app than during the checkpoint. This sounds like a wonderful approach to me, and much better than what I was thinking of. What kind of mechanism do you have in mind? int sys_remap_file_pages(...) { ... oh_crap_we_dont_support_this_yet(current); } Then the oh_crap..() function sets a task flag or something? -- Dave -- 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: email@kvack.org