Linux Container Development
 help / color / mirror / Atom feed
From: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
To: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
Subject: Re: bugs with ckpt-v15-dev
Date: Wed, 20 May 2009 01:30:06 -0400	[thread overview]
Message-ID: <4A13955E.2040301@cs.columbia.edu> (raw)
In-Reply-To: <20090519010911.GD28083-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>



Matt Helsley wrote:
> On Mon, May 18, 2009 at 06:21:22PM -0500, Nathan Lynch wrote:
>> Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
>>
>>> On Mon, May 18, 2009 at 04:36:11PM -0500, Nathan Lynch wrote:
>>>> [1] Should CONFIG_CHECKPOINT depend on CONFIG_CGROUPS and/or
>>>> CONFIG_CGROUPS_FREEZER?  We require tasks to be put in frozen state
>>>> before checkpoint, is there any mechanism apart from
>>>> cgroup/freezer.state to do this?
>>> Have you tried sending all of the tasks SIGSTOP? It won't 100% freeze
>>> the tasks -- they'd still be capable of responding to some signals
>>> (CONT, TERM..). Also they'd presumably be placed in the stopped state
>>> upon restart so a SIGCONT will be needed. In the case of bash, at
>>> least, that will technically change what happens upon restart. My
>>> guess is that in many cases it won't matter but there are some where
>>> it will.
>> Hmm, I'm having trouble understanding your suggestion.  The current
>> checkpoint implementation requires non-self tasks to be frozen (p->flags
>> & PF_FROZEN), which is not equivalent to stopped state (task->state &
>> __TASK_STOPPED).  That is, it would refuse to checkpoint tasks in
>> stopped state.  See may_checkpoint_task().
> 
> Oops. You're right. That would require changing may_checkpoint_task() to include
> __TASK_STOPPED -- not something we'd want in the final code. I had assumed
> you wanted to try a different mechanism for debugging purposes.
> 

Allowing checkpoint of stopped tasks is actually not such a bad
idea, IMHO.

Oren.

  parent reply	other threads:[~2009-05-20  5:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-18 19:23 bugs with ckpt-v15-dev Nathan Lynch
     [not found] ` <m3my9amczw.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-05-18 21:10   ` Serge E. Hallyn
     [not found]     ` <20090518211041.GA20781-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-18 21:36       ` Nathan Lynch
     [not found]         ` <m3y6suhz5g.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-05-18 22:39           ` Serge E. Hallyn
     [not found]             ` <20090518223919.GA24826-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-18 23:02               ` Nathan Lynch
2009-05-18 22:51           ` Matt Helsley
     [not found]             ` <20090518225100.GC28083-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-18 23:21               ` Nathan Lynch
     [not found]                 ` <m3zldagfpp.fsf-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
2009-05-19  1:09                   ` Matt Helsley
     [not found]                     ` <20090519010911.GD28083-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-20  5:30                       ` Oren Laadan [this message]
     [not found]                         ` <4A13955E.2040301-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-05-20 13:14                           ` Serge E. Hallyn
     [not found]                             ` <20090520131457.GB25989-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-20 13:21                               ` Oren Laadan
2009-05-20 21:10                               ` Matt Helsley
2009-05-20  5:28   ` 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=4A13955E.2040301@cs.columbia.edu \
    --to=orenl-eqauephvms7envbuuze7ea@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox