[Devel] Re: [RFC v14-rc2][PATCH 15/29] Restart multiple processes
Sukadev Bhattiprolu
sukadev at linux.vnet.ibm.com
Tue Apr 7 09:29:29 PDT 2009
Oren Laadan [orenl at cs.columbia.edu] wrote:
| Sukadev Bhattiprolu wrote:
| >
| > Secondly, isn't pids_nr same as tasks_nr ? If so do we need both ?
|
| As the comment says: one is used exclusively for checkpoint and the
| other exclusively for restart.
| So we don't strictly need both. I thought that for readability of it's
| useful to have @pids_nr (ok, @nr_pids ...) when dealing with a @pids_arr,
| and a @tasks_nr (ok .. @nr_tasks ...) when dealing with @tasks_arr.
|
| >
| > Or is this intended to address the issue of multiple pid_nr values that a
| > task in a nested container can have ? If so, pids_nr is > tasks_nr and that
| > brings up two comments :-)
|
| Ugh. This topic is TBD.
|
| >
| > First, mktree.c and cr_next_task() are using 'ctx->pids_nr' to determine how
| > many tasks to start. If we are talking about nested containers, pids_nr
| > will be greater than tasks_nr so, mktree and cr_next_task() should be
| > use 'ctx->tasks_nr' to determine how many tasks to create. Also if
| > checkpointing a nested container we should view the multiple nested pid
| > values a process as an attribute of the task and maybe save them in
| > cr_write_task() rather than in cr_write_tree().
|
| Lol .. who's talking about nested containers ? ;)
:-) I guess the presence of both pids_nr and tasks_nr in the same structure
threw me off. Yes, ignoring nested containers for now is really good :-)
Maybe we can add a check in cr_may_checkpoint() to fail if any task in
the process tree has :
pid->level != task_pid(current)->level + 1
so nested containers fail cleanly.
|
| (seriously: I'm not considering that now; my gut feeling is that it may
| be useful to do pid_ns in userspace, like task creation - and in that
| case it makes sense to keep it in cr_write_tree(). then again, I have
| not looked at it in depth).
|
| >
| > My second comment is more an orthogonal question. Suppose init_pid_ns = level
| > 0 and we have a container that is nested at level 3. If we checkpoint just
| > this container, we would want to be able to restore this container at any level
| > 0 right ?
|
| True. Do you see any limitation in the current code that prevents this ?
No I did not see anything. I mentioned it because the the number of pids
associated with the task will change and we have to discard some pids
during restart. But lets not worry about it now :-)
Sukadev
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list