OpenVZ Forum - RDF feed
type: channel
items: [PATCH 01/10] Containers(V10): Basic container framework
items: Re: [PATCH 01/10] Containers(V10): Basic container framework

[PATCH 01/10] Containers(V10): Basic container framework
type: item
description: This patch adds the main containers framework - the container filesystem, and the basic structures for tracking membership and associating subsystem state objects to tasks. Signed-off-by: Paul Menage <menage@google.com> --- Documentation/containers.txt | 524 +++++++++++++++++ include/linux/container.h | 198 ++++++ include/linux/container_subsys.h | 10 include/linux/sched.h | 34 + init/Kconfig | 3 init/main.c | 3 kernel/Makefile | 1 kernel/container.c | 1155 +++++++++++++++++++++++++++++++++++++++ 8 files changed, 1927 insertions(+), 1 deletion(-) Index: container-2.6.22-rc2-mm1/Documentation/containers.txt ============================================================ ======= --- /dev/null +++ container-2.6.22-rc2-mm1/Documentation/containers.txt @@ -0,0 +1,524 @@ + CONTAINERS + ------- + +Written by Paul Menage <menage@google.com> based on Documentation/cpusets.txt + +Original copyright statements from cpusets.txt: +Portions Copyright (C) 2004 BULL SA. +Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. +Modified by Paul Jackson <pj@sgi.com> +Modified by Christoph Lameter <clameter@sgi.com> + +CONTENTS: +========= + +1. Containers + 1.1 What are containers ? + 1.2 Why are containers needed ? + 1.3 How are containers implemented ? + 1.4 What does notify_on_release do ? + 1.5 How do I use containers ? +2. Usage Examples and Syntax + 2.1 Basic Usage + 2.2 Attaching processes +3. Kernel API + 3.1 Overview + 3.2 Synchronization + 3.3 Subsystem API +4. Questions + +1. Containers +========== + +1.1 What are containers ? +---------------------- + +Containers provide a mechanism for aggregating/partitioning sets of +tasks, and all their future children, into hierarchical groups with +specialized behaviour. + +Definitions: + +A *container* associates a set of tasks with a set of parameters for one +or more subsystems. + +A *subsystem* is a module that makes use of the task grouping +facilities provided by containers to treat groups of tasks in +particular ways. A subsyste…
creator: Paul Menage
date: 2007-05-29T13:01:05-00:00

Re: [PATCH 01/10] Containers(V10): Basic container framework
type: item
description: On Tue, 29 May 2007 06:01:05 -0700 menage@google.com wrote: > +For example, the following sequence of commands will setup a container > +named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, > +and then start a subshell 'sh' in that container: > + > + mount -t container cpuset -ocpuset /dev/container > + cd /dev/container > + mkdir Charlie > + cd Charlie > + /bin/echo $$ > tasks > + sh > + # The subshell 'sh' is now running in container Charlie > + # The next line should display '/Charlie' > + cat /proc/self/container Once this has been done, can tasks inside `Charlie' escape from it? And what permissions are needed to expand the various allotments (if that's the approved term) for `Charlie'?
creator: Andrew Morton
date: 2007-05-30T07:15:02-00:00

Re: [PATCH 01/10] Containers(V10): Basic container framework
type: item
description: On Tue, 29 May 2007 06:01:05 -0700 menage@google.com wrote: > This patch adds the main containers framework - the container > filesystem, and the basic structures for tracking membership and > associating subsystem state objects to tasks. > > ... > > --- /dev/null > +++ container-2.6.22-rc2-mm1/include/linux/container_subsys.h > @@ -0,0 +1,10 @@ > +/* Add subsystem definitions of the form SUBSYS(<name>) in this > + * file. Surround each one by a line of comment markers so that > + * patches don't collide > + */ > + > +/* */ > + > +/* */ > + > +/* */ > Index: container-2.6.22-rc2-mm1/include/linux/sched.h > ============================================================ ======= > --- container-2.6.22-rc2-mm1.orig/include/linux/sched.h > +++ container-2.6.22-rc2-mm1/include/linux/sched.h > @@ -851,6 +851,34 @@ struct sched_class { > void (*task_new) (struct rq *rq, struct task_struct *p); > }; > > +#ifdef CONFIG_CONTAINERS > + > +#define SUBSYS(_x) _x ## _subsys_id, > +enum container_subsys_id { > +#include <linux/container_subsys.h> > + CONTAINER_SUBSYS_COUNT > +}; > +#undef SUBSYS > + > +/* A css_group is a structure holding pointers to a set of > + * container_subsys_state objects. > + */ > + > +struct css_group { > + > + /* Set of subsystem states, one for each subsystem. NULL for > + * subsystems that aren't part of this hierarchy. These > + * pointers reduce the number of dereferences required to get > + * from a task to its state for a given container, but result > + * in increased space usage if tasks are in wildly different > + * groupings across different hierarchies. This array is > + * immutable after creation */ > + struct container_subsys_state *subsys[CONTAINER_SUBSYS_COUNT]; > + > +}; hm, missing forward declaration of struct container_subsys_state, but it all seems to work out (via nested include) once the patches are applied and the config option is enableable. > > ... > > --- /dev/null > +++ container-2.6.22-rc2-mm1/kernel/container.c > > ... > > +#inc…
creator: Andrew Morton
date: 2007-05-30T07:15:52-00:00

Re: [PATCH 01/10] Containers(V10): Basic container framework
type: item
description: On 5/30/07, Andrew Morton <akpm@linux-foundation.org> wrote: > > Holy cow, do we need all those? I'll experiment to see which ones we can get rid of. > > > +typedef enum { > > + CONT_REMOVED, > > +} container_flagbits_t; > > typedefs are verboten. Fortunately this one is never referred to - only > the values are used, so we can delete it. OK. > > Taking dcache_lock in here is unfortunate. A filesystem really shouldn't > be playing with that lock. Is there a recommended way to do what I want to do, i.e. clear out all the dentries from a virtual fs directory and rebuild them whilst holding the directory's i_sem so no one can see the transiently empty directory? > > The code's a bit short on comments. I'll add some. > > + root = d_alloc_root(inode); > > + if (!root) { > > + iput(inode); > > + return -ENOMEM; > > I bet that iput() hasn't been tested ;) Correct. > > People have hit unpleasant problems before now running iput() against > partially-constructed inodes. What kinds of problems? Are there bits of state that I should fully construct even if I'm going to iput() it, or is there a better function to call? fs/ext3/super.c seems to do the same thing. > > + if (ret) > > + goto out_unlock; > > Did we just leak *root? I believe we did. I'll fix that. > > > > +static inline void get_first_subsys(const struct container *cont, > > + struct container_subsys_state **css, > > + int *subsys_id) { > > + const struct containerfs_root *root = cont->root; > > + const struct container_subsys *test_ss; > > + BUG_ON(list_empty(&root->subsys_list)); > > + test_ss = list_entry(root->subsys_list.next, > > + struct container_subsys, sibling); > > + if (css) { > > + *css = cont->subsys[test_ss->subsys_id]; > > + BUG_ON(!*css); > > + } > > + if (subsys_id) > > + *subsys_id = test_ss->subsys_id; > > +} > > This ends up having several callers and its too large to inline. Two large from a compiler PoV or from a style PoV? It's basically just six dereferences and two comparisons, plus the BUG…
creator: Paul Menage
date: 2007-05-30T14:02:00-00:00

Re: [PATCH 01/10] Containers(V10): Basic container framework
type: item
description: On Wed, 30 May 2007 07:02:00 -0700 "Paul Menage" <menage@google.com> wrote: > > > > > People have hit unpleasant problems before now running iput() against > > partially-constructed inodes. > > What kinds of problems? Are there bits of state that I should fully > construct even if I'm going to iput() it, or is there a better > function to call? fs/ext3/super.c seems to do the same thing. I don't recall, actually. But it crashed. I guess the fault-injection code could be used to trigger errors here. > > > > > > +static inline void get_first_subsys(const struct container *cont, > > > + struct container_subsys_state **css, > > > + int *subsys_id) { > > > + const struct containerfs_root *root = cont->root; > > > + const struct container_subsys *test_ss; > > > + BUG_ON(list_empty(&root->subsys_list)); > > > + test_ss = list_entry(root->subsys_list.next, > > > + struct container_subsys, sibling); > > > + if (css) { > > > + *css = cont->subsys[test_ss->subsys_id]; > > > + BUG_ON(!*css); > > > + } > > > + if (subsys_id) > > > + *subsys_id = test_ss->subsys_id; > > > +} > > > > This ends up having several callers and its too large to inline. > > Two large from a compiler PoV or from a style PoV? It's basically just > six dereferences and two comparisons, plus the BUG_ON()s. It will end up generating more .text this way. We figure that this makes it slower, due to increased icache footprint.
creator: Andrew Morton
date: 2007-05-30T16:00:31-00:00

Re: [PATCH 01/10] Containers(V10): Basic container framework
type: item
description: Hi, On Tue, May 29, 2007 at 06:01:05AM -0700, menage@google.com wrote: > +1.5 How do I use containers ? > +-------------------------- > + > +To start a new job that is to be contained within a container, using > +the "cpuset" container subsystem, the steps are something like: > + > + 1) mkdir /dev/container > + 2) mount -t container -ocpuset cpuset /dev/container > + 3) Create the new container by doing mkdir's and write's (or echo's) in > + the /dev/container virtual file system. > + 4) Start a task that will be the "founding father" of the new job. > + 5) Attach that task to the new container by writing its pid to the > + /dev/container tasks file for that container. > + 6) fork, exec or clone the job tasks from this founding father task. > + > +For example, the following sequence of commands will setup a container > +named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, > +and then start a subshell 'sh' in that container: > + > + mount -t container cpuset -ocpuset /dev/container > + cd /dev/container > + mkdir Charlie > + cd Charlie This example does not work. To do so we need to do /bin/echo 2-3 > cpus /bin/echo 1 > mems > + /bin/echo $$ > tasks > + sh > + # The subshell 'sh' is now running in container Charlie > + # The next line should display '/Charlie' > + cat /proc/self/container The following patch does that. thanks and regards Dhaval ---------------------- Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com> diff -uprN linux-2.6.22-rc4/Documentation/containers.txt old/Documentation/containers.txt --- linux-2.6.22-rc4/Documentation/containers.txt 2007-06-13 15:38:30.000000000 +0530 +++ old/Documentation/containers.txt 2007-06-13 10:56:49.000000000 +0530 @@ -310,6 +310,8 @@ and then start a subshell 'sh' in that c cd /dev/container mkdir Charlie cd Charlie + /bin/echo 2-3 > cpus + /bin/echo 1 > mems /bin/echo $$ > tasks sh # The subshell 'sh' is now running in container Charlie
creator: Dhaval Giani
date: 2007-06-13T10:17:38-00:00