[Devel] Re: [PATCH 22/28] [MULTI 1/6] Changes in data structures for multilevel model

sukadev at us.ibm.com sukadev at us.ibm.com
Mon Jun 18 23:32:50 PDT 2007


Pavel Emelianov [xemul at openvz.org] wrote:
| This patch opens the multilevel model patches.
| 
| The multilevel model idea is basically the same as for the flat one,
| but in this case task may have many virtual pids - one id for each 
| sub-namespace this task is visible in. The struct pid carries the 
| list of pid_number-s and two hash tables are used to find this number
| by numerical id and by struct pid.
| 
| 
| 
| The struct pid doesn't need the numerical ids any longer. Instead it
| has a single linked list of struct pid_number-s which are hashed
| for quick search and have the numerical id.
| 
| Signed-off-by: Pavel Emelianov <xemul at openvz.org>
| 
| ---
| 
|  pid.h |   31 +++++++++++++++++++++++++++++++
|  1 files changed, 31 insertions(+)
| 
| --- ./include/linux/pid.h.multdatast	2007-06-15 15:23:00.000000000 +0400
| +++ ./include/linux/pid.h	2007-06-15 15:32:15.000000000 +0400
| @@ -50,9 +50,33 @@ enum pid_type
|   * id must be used.
|   */
| 
| +/*
| + * multilevel pid namespaces
| + * each task may belong to any number of namespaces and thus struct pid do
| + * not carry the number any longer. instead if this struct pid has a list of
| + * pid_number-s each belonging to one namespace. two hashes are used to find
| + * the number - by the numerical id and by the struct pid this nr belongs to.
| + * this allows for creating namespaces of infinite nesting, but has slight
| + * performance problems.
| + */
| +
| +struct pid_number
| +{
| +	int nr;
| +	struct pid_namespace *ns;
| +	struct pid *pid;
| +
| +	struct hlist_node pid_chain;
| +	struct hlist_node nr_chain;
| +	struct pid_number *next;

As you probably noticed, we had a similar linked list until recently.
But since we use only clone() to create a new pid namespace, we figured
we could use an array of 'struct pid_number' elements. That may perform
slightly better since all 'pid_number elements' are co-located.

We obviously need a list like this if we unshare (rather than clone())
pid namespace.

I have a few questions - not that I see any problems yet - just for my
understanding (they may be addressed in other patches, but am still
reviewing them).

	- Can one process unshare() its namespace, create a few children,
	  and unshare its namespace again ? 

	- If so, will that same process be the reaper for multiple pid
	  namespaces ?

	- Will we terminate all those namespaces if the reaper is terminated ?


| +};
| +
|  struct pid
|  {
|  	atomic_t count;
| +#ifdef CONFIG_PID_NS_MULTILEVEL
| +	struct pid_number *pid_nrs;
| +#else
|  	/* Try to keep pid_chain in the same cacheline as nr for find_pid */
|  	int nr;
|  	struct hlist_node pid_chain;
| @@ -65,11 +89,18 @@ struct pid
|  	struct pid_namespace *ns;
|  	struct hlist_node vpid_chain;
|  #endif
| +#endif
|  	/* lists of tasks that use this pid */
|  	struct hlist_head tasks[PIDTYPE_MAX];
|  	struct rcu_head rcu;
|  };
| 
| +#ifdef CONFIG_PID_NS_MULTILEVEL
| +/* small helper to iterate over the pid's numbers */
| +#define for_each_pid_nr(nr, pid) \
| +		for (nr = pid->pid_nrs; nr != NULL; nr = nr->next)
| +#endif
| +
|  extern struct pid init_struct_pid;
| 
|  struct pid_link
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list