Li Zefan wrote:
>  *** notify_on_release is disabled in the current patch set. It will be
> -*** reactivated in a future patch in a less-intrusive manner
> +*** reactivated in a future patch in a less-intrusive manner.

Someone should verify this, but I'm pretty sure that notify_on_release
is now working ... no longer disabled.  I believe the above line from
the documentation is out of date.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Paul Jackson wrote:
> Li Zefan wrote:
>>  *** notify_on_release is disabled in the current patch set. It will be
>> -*** reactivated in a future patch in a less-intrusive manner
>> +*** reactivated in a future patch in a less-intrusive manner.
> 
> Someone should verify this, but I'm pretty sure that notify_on_release
> is now working ... no longer disabled.  I believe the above line from
> the documentation is out of date.
> 

Aha, it does work now. I tried it but it didn't seem to work, maybe I didn't
something wrong. I'll resend a new patch.

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Misc fixes and updates, make the doc consistent with current
cgroup implementation.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
 Documentation/cgroups.txt |   66 ++++++++++++++++++++++----------------------
 1 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt
index 42d7c4c..31d12e2 100644
--- a/Documentation/cgroups.txt
+++ b/Documentation/cgroups.txt
@@ -28,7 +28,7 @@ CONTENTS:
 4. Questions
 
 1. Control Groups
-==========
+=================
 
 1.1 What are cgroups ?
 ----------------------
@@ -143,10 +143,10 @@ proliferation of such cgroups.
 
 Also lets say that the administrator would like to give enhanced network
 access temporarily to a student's browser (since it is night and the user
-wants to do online gaming :)  OR give one of the students simulation
+wants to do online gaming :))  OR give one of the students simulation
 apps enhanced CPU power,
 
-With ability to write pids directly to resource classes, its just a
+With ability to write pids directly to resource classes, it's just a
 matter of :
 
        # echo pid > /mnt/network/<new_class>/tasks
@@ -227,10 +227,13 @@ Each cgroup is represented by a directory in the cgroup file system
 containing the following files describing that cgroup:
 
  - tasks: list of tasks (by pid) attached to that cgroup
- - notify_on_release flag: run /sbin/cgroup_release_agent on exit?
+ - releasable flag: cgroup currently removeable?
+ - notify_on_release flag: run the release agent on exit?
+ - release_agent: the path to use for release notifications (this file
+   exists in the top cgroup only)
 
 Other subsystems such as cpusets may add additional files in each
-cgroup dir
+cgroup dir.
 
 New cgroups are created using the mkdir system call or shell
 command.  The properties of a cgroup, such as its flags, are
@@ -257,7 +260,7 @@ performance.
 To allow access from a cgroup to the css_sets (and hence tasks)
 that comprise it, a set of cg_cgroup_link objects form a lattice;
 each cg_cgroup_link is linked into a list of cg_cgroup_links for
-a single cgroup on its cont_link_list field, and a list of
+a single cgroup on its cgrp_link_list field, and a list of
 cg_cgroup_links for a single css_set on its cg_link_list.
 
 Thus the set of tasks in a cgroup can be listed by iterating over
@@ -271,9 +274,6 @@ for cgroups, with a minimum of additional kernel code.
 1.4 What does notify_on_release do ?
 ------------------------------------
 
-*** notify_on_release is disabled in the current patch set. It will be
-*** reactivated in a future patch in a less-intrusive manner
-
 If the notify_on_release flag is enabled (1) in a cgroup, then
 whenever the last task in the cgroup leaves (exits or attaches to
 some other cgroup) and the last child cgroup of that cgroup
@@ -360,8 +360,8 @@ Now you want to do something with this cgroup.
 
 In this directory you can find several files:
 # ls
-notify_on_release release_agent tasks
-(plus whatever files are added by the attached subsystems)
+notify_on_release releasable tasks
+(plus whatever files added by the attached subsystems)
 
 Now attach your shell to this cgroup:
 # /bin/echo $$ > tasks
@@ -404,19 +404,13 @@ with a subsystem id which will be assigned by the cgroup system.
 Other fields in the cgroup_subsys object include:
 
 - subsys_id: a unique array index for the subsystem, indicating which
-  entry in cgroup->subsys[] this subsystem should be
-  managing. Initialized by cgroup_register_subsys(); prior to this
-  it should be initialized to -1
+  entry in cgroup->subsys[] this subsystem should be managing.
 
-- hierarchy: an index indicating which hierarchy, if any, this
-  subsystem is currently attached to. If this is -1, then the
-  subsystem is not attached to any hierarchy, and all tasks should be
-  considered to be members of the subsystem's top_cgroup. It should
-  be initialized to -1.
+- name: should be initialized to a unique subsystem name. Should be
+  no longer than MAX_CGROUP_TYPE_NAMELEN.
 
-- name: should be initialized to a unique subsystem name prior to
-  calling cgroup_register_subsystem. Should be no longer than
-  MAX_CGROUP_TYPE_NAMELEN
+- early_init: indicate if the subsystem needs early initialization
+  at system boot.
 
 Each cgroup object created by the system has an array of pointers,
 indexed by subsystem id; this pointer is entirely managed by the
@@ -434,8 +428,6 @@ situation.
 See kernel/cgroup.c for more details.
 
 Subsystems can take/release the cgroup_mutex via the functions
-cgroup_lock()/cgroup_unlock(), and can
-take/release the callback_mutex via the functions
 cgroup_lock()/cgroup_unlock().
 
 Accessing a task's cgroup pointer may be done in the following ways:
@@ -444,7 +436,7 @@ Accessing a task's cgroup pointer may be done in the following ways:
 - inside an rcu_read_lock() section via rcu_dereference()
 
 3.3 Subsystem API
---------------------------
+-----------------
 
 Each subsystem should:
 
@@ -455,7 +447,8 @@ Each subsystem may export the following methods. The only mandatory
 methods are create/destroy. Any others that are null are presumed to
 be successful no-ops.
 
-struct cgroup_subsys_state *create(struct cgroup *cont)
+struct cgroup_subsys_state *create(struct cgroup_subsys *ss,
+				   struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 
 Called to create a subsystem state object for a cgroup. The
@@ -470,7 +463,7 @@ identified by the passed cgroup object having a NULL parent (since
 it's the root of the hierarchy) and may be an appropriate place for
 initialization code.
 
-void destroy(struct cgroup *cont)
+void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 
 The cgroup system is about to destroy the passed cgroup; the subsystem
@@ -481,7 +474,14 @@ cgroup->parent is still valid. (Note - can also be called for a
 newly-created cgroup if an error occurs after this subsystem's
 create() method has been called for the new cgroup).
 
-int can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
+void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
+(cgroup_mutex held by caller)
+
+Called before checking the reference count on each subsystem. This may
+be useful for subsystems which have some extra references even if
+there are not tasks in the cgroup.
+
+int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
 	       struct task_struct *task)
 (cgroup_mutex held by caller)
 
@@ -492,8 +492,8 @@ unspecified task can be moved into the cgroup. Note that this isn't
 called on a fork. If this method returns 0 (success) then this should
 remain valid while the caller holds cgroup_mutex.
 
-void attach(struct cgroup_subsys *ss, struct cgroup *cont,
-	    struct cgroup *old_cont, struct task_struct *task)
+void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
+	    struct cgroup *old_cgrp, struct task_struct *task)
 
 Called after the task has been attached to the cgroup, to allow any
 post-attachment activity that requires memory allocations or blocking.
@@ -505,9 +505,9 @@ registration for all existing tasks.
 
 void exit(struct cgroup_subsys *ss, struct task_struct *task)
 
-Called during task exit
+Called during task exit.
 
-int populate(struct cgroup_subsys *ss, struct cgroup *cont)
+int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
 
 Called after creation of a cgroup to allow a subsystem to populate
 the cgroup directory with file entries.  The subsystem should make
@@ -516,7 +516,7 @@ include/linux/cgroup.h for details).  Note that although this
 method can return an error code, the error code is currently not
 always handled well.
 
-void post_clone(struct cgroup_subsys *ss, struct cgroup *cont)
+void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
 
 Called at the end of cgroup_clone() to do any paramater
 initialization which might be required before a task could attach.  For
-- 
1.5.4.rc3

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

On Feb 18, 2008 12:39 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> Misc fixes and updates, make the doc consistent with current
> cgroup implementation.
>
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>

Acked-by: Paul Menage <menage@google.com>

Thanks for these cleanups.

Paul

> ---
>  Documentation/cgroups.txt |   66 ++++++++++++++++++++++----------------------
>  1 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt
> index 42d7c4c..31d12e2 100644
>
> --- a/Documentation/cgroups.txt
> +++ b/Documentation/cgroups.txt
> @@ -28,7 +28,7 @@ CONTENTS:
>  4. Questions
>
>  1. Control Groups
> -==========
> +=================
>
>  1.1 What are cgroups ?
>  ----------------------
> @@ -143,10 +143,10 @@ proliferation of such cgroups.
>
>  Also lets say that the administrator would like to give enhanced network
>  access temporarily to a student's browser (since it is night and the user
> -wants to do online gaming :)  OR give one of the students simulation
> +wants to do online gaming :))  OR give one of the students simulation
>  apps enhanced CPU power,
>
> -With ability to write pids directly to resource classes, its just a
> +With ability to write pids directly to resource classes, it's just a
>  matter of :
>
>         # echo pid > /mnt/network/<new_class>/tasks
> @@ -227,10 +227,13 @@ Each cgroup is represented by a directory in the cgroup file system
>  containing the following files describing that cgroup:
>
>   - tasks: list of tasks (by pid) attached to that cgroup
> - - notify_on_release flag: run /sbin/cgroup_release_agent on exit?
> + - releasable flag: cgroup currently removeable?
> + - notify_on_release flag: run the release agent on exit?
> + - release_agent: the path to use for release notifications (this file
> +   exists in the top cgroup only)
>
>  Other subsystems such as cpusets may add additional files in each
> -cgroup dir
> +cgroup dir.
>
>  New cgroups are created using the mkdir system call or shell
>  command.  The properties of a cgroup, such as its flags, are
> @@ -257,7 +260,7 @@ performance.
>  To allow access from a cgroup to the css_sets (and hence tasks)
>  that comprise it, a set of cg_cgroup_link objects form a lattice;
>  each cg_cgroup_link is linked into a list of cg_cgroup_links for
> -a single cgroup on its cont_link_list field, and a list of
> +a single cgroup on its cgrp_link_list field, and a list of
>  cg_cgroup_links for a single css_set on its cg_link_list.
>
>  Thus the set of tasks in a cgroup can be listed by iterating over
> @@ -271,9 +274,6 @@ for cgroups, with a minimum of additional kernel code.
>  1.4 What does notify_on_release do ?
>  ------------------------------------
>
> -*** notify_on_release is disabled in the current patch set. It will be
> -*** reactivated in a future patch in a less-intrusive manner
> -
>  If the notify_on_release flag is enabled (1) in a cgroup, then
>  whenever the last task in the cgroup leaves (exits or attaches to
>  some other cgroup) and the last child cgroup of that cgroup
> @@ -360,8 +360,8 @@ Now you want to do something with this cgroup.
>
>  In this directory you can find several files:
>  # ls
> -notify_on_release release_agent tasks
> -(plus whatever files are added by the attached subsystems)
> +notify_on_release releasable tasks
> +(plus whatever files added by the attached subsystems)
>
>  Now attach your shell to this cgroup:
>  # /bin/echo $$ > tasks
> @@ -404,19 +404,13 @@ with a subsystem id which will be assigned by the cgroup system.
>  Other fields in the cgroup_subsys object include:
>
>  - subsys_id: a unique array index for the subsystem, indicating which
> -  entry in cgroup->subsys[] this subsystem should be
> -  managing. Initialized by cgroup_register_subsys(); prior to this
> -  it should be initialized to -1
> +  entry in cgroup->subsys[] this subsystem should be managing.
>
> -- hierarchy: an index indicating which hierarchy, if any, this
> -  subsystem is currently attached to. If this is -1, then the
> -  subsystem is not attached to any hierarchy, and all tasks should be
> -  considered to be members of the subsystem's top_cgroup. It should
> -  be initialized to -1.
> +- name: should be initialized to a unique subsystem name. Should be
> +  no longer than MAX_CGROUP_TYPE_NAMELEN.
>
> -- name: should be initialized to a unique subsystem name prior to
> -  calling cgroup_register_subsystem. Should be no longer than
> -  MAX_CGROUP_TYPE_NAMELEN
> +- early_init: indicate if the subsystem needs early initialization
> +  at system boot.
>
>  Each cgroup object created by the system has an array of pointers,
>  indexed by subsystem id; this pointer is entirely managed by the
> @@ -434,8 +428,6 @@ situation.
>  See kernel/cgroup.c for more details.
>
>  Subsystems can take/release the cgroup_mutex via the functions
> -cgroup_lock()/cgroup_unlock(), and can
> -take/release the callback_mutex via the functions
>  cgroup_lock()/cgroup_unlock().
>
>  Accessing a task's cgroup pointer may be done in the following ways:
> @@ -444,7 +436,7 @@ Accessing a task's cgroup pointer may be done in the following ways:
>  - inside an rcu_read_lock() section via rcu_dereference()
>
>  3.3 Subsystem API
> ---------------------------
> +-----------------
>
>  Each subsystem should:
>
> @@ -455,7 +447,8 @@ Each subsystem may export the following methods. The only mandatory
>  methods are create/destroy. Any others that are null are presumed to
>  be successful no-ops.
>
> -struct cgroup_subsys_state *create(struct cgroup *cont)
> +struct cgroup_subsys_state *create(struct cgroup_subsys *ss,
> +                                  struct cgroup *cgrp)
>  (cgroup_mutex held by caller)
>
>  Called to create a subsystem state object for a cgroup. The
> @@ -470,7 +463,7 @@ identified by the passed cgroup object having a NULL parent (since
>  it's the root of the hierarchy) and may be an appropriate place for
>  initialization code.
>
> -void destroy(struct cgroup *cont)
> +void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)
>  (cgroup_mutex held by caller)
>
>  The cgroup system is about to destroy the passed cgroup; the subsystem
> @@ -481,7 +474,14 @@ cgroup->parent is still valid. (Note - can also be called for a
>  newly-created cgroup if an error occurs after this subsystem's
>  create() method has been called for the new cgroup).
>
> -int can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
> +void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
> +(cgroup_mutex held by caller)
> +
> +Called before checking the reference count on each subsystem. This may
> +be useful for subsystems which have some extra references even if
> +there are not tasks in the cgroup.
> +
> +int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
>                struct task_struct *task)
>  (cgroup_mutex held by caller)
>
> @@ -492,8 +492,8 @@ unspecified task can be moved into the cgroup. Note that this isn't
>  called on a fork. If this method returns 0 (success) then this should
>  remain valid while the caller holds cgroup_mutex.
>
> -void attach(struct cgroup_subsys *ss, struct cgroup *cont,
> -           struct cgroup *old_cont, struct task_struct *task)
> +void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
> +           struct cgroup *old_cgrp, struct task_struct *task)
>
>  Called after the task has been attached to the cgroup, to allow any
>  post-attachment activity that requires memory allocations or blocking.
> @@ -505,9 +505,9 @@ registration for all existing tasks.
>
>  void exit(struct cgroup_subsys *ss, struct task_struct *task)
>
> -Called during task exit
> +Called during task exit.
>
> -int populate(struct cgroup_subsys *ss, struct cgroup *cont)
> +int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
>
>  Called after creation of a cgroup to allow a subsystem to populate
>  the cgroup directory with file entries.  The subsystem should make
> @@ -516,7 +516,7 @@ include/linux/cgroup.h for details).  Note that although this
>
>  method can return an error code, the error code is currently not
>  always handled well.
>
> -void post_clone(struct cgroup_subsys *ss, struct cgroup *cont)
> +void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
>
>  Called at the end of cgroup_clone() to do any paramater
>  initialization which might be required before a task could attach.  For
> --
> 1.5.4.rc3
>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers