[RFC][PATCH] NOOP cgroup subsystem

[RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

How about this idea ? Any comments are welcome.

-Kame

==
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

Add an NO OPERATION cgroup subsystem.

Cgroup itself is providing a feature to attach a task(PID) to some class.
This feature itself is very useful but "no operation" cgroup is not supported
now other than debug cgroup. (But debug cgroup should be for DEBUG. distro
may not configure it.)

Motivation: Simply classify Applications by cgroup
  When using cgroup for classifying applications, some kind of "control" or
  "account" subsys must be used. For flexible use of cgroup's nature of
  classifying applications, NOOP is useful. It can be used regardless of
  resource accounting unit or name spaces or some controls.
  IOW, NOOP cgroup allows users to tie PIDs with some nickname.

After this, application can be checked whether it's still alive or not by

	mount -t cgroup none /var/apps noop
	mkdir /var/apps/mydaemon
	echo 0 > /var/apps/mydaemon
	/etc/init.d/mydaemon start
	exit

This can be used as the same technique of "recording pid into /var/run/xxx.pid"
and not necessary to remove stale files. If mydaemon dies, tasks file will
be empty and notify_on_release handler can be used.

I myself want to use this for replacement of "ps -elf | grep" if libcgroup supports
ps under cgroup.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
 include/linux/cgroup_subsys.h |    4 ++++
 init/Kconfig                  |    9 +++++++++
 kernel/Makefile               |    1 +
 kernel/cgroup_noop.c          |   34 ++++++++++++++++++++++++++++++++++
 4 files changed, 48 insertions(+)

Index: mmotm-2.6.28-Jan8/include/linux/cgroup_subsys.h
===================================================================
--- mmotm-2.6.28-Jan8.orig/include/linux/cgroup_subsys.h
+++ mmotm-2.6.28-Jan8/include/linux/cgroup_subsys.h
@@ -59,4 +59,8 @@ SUBSYS(freezer)
 SUBSYS(net_cls)
 #endif
 
+#ifdef CONFIG_CGROUP_NOOP
+SUBSYS(noop)
+#endif
+
 /* */
Index: mmotm-2.6.28-Jan8/kernel/Makefile
===================================================================
--- mmotm-2.6.28-Jan8.orig/kernel/Makefile
+++ mmotm-2.6.28-Jan8/kernel/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_CGROUP_DEBUG) += cgroup_deb
 obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
+obj-$(CONFIG_CGROUP_NOOP) += cgroup_noop.o
 obj-$(CONFIG_UTS_NS) += utsname.o
 obj-$(CONFIG_USER_NS) += user_namespace.o
 obj-$(CONFIG_PID_NS) += pid_namespace.o
Index: mmotm-2.6.28-Jan8/kernel/cgroup_noop.c
===================================================================
--- /dev/null
+++ mmotm-2.6.28-Jan8/kernel/cgroup_noop.c
@@ -0,0 +1,34 @@
+/*
+ * kernel/cgroup_noop.c - No Operation Cgroup. Just for organizing process tree
+ */
+
+#include <linux/cgroup.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/rcupdate.h>
+
+#include <asm/atomic.h>
+
+static struct cgroup_subsys_state *noop_create(struct cgroup_subsys *ss,
+						   struct cgroup *cont)
+{
+	struct cgroup_subsys_state *css = kzalloc(sizeof(*css), GFP_KERNEL);
+
+	if (!css)
+		return ERR_PTR(-ENOMEM);
+
+	return css;
+}
+
+static void noop_destroy(struct cgroup_subsys *ss, struct cgroup *cont)
+{
+	kfree(cont->subsys[noop_subsys_id]);
+}
+
+
+struct cgroup_subsys noop_subsys = {
+	.name = "noop",
+	.subsys_id = noop_subsys_id,
+	.create = noop_create,
+	.destroy = noop_destroy,
+};
Index: mmotm-2.6.28-Jan8/init/Kconfig
===================================================================
--- mmotm-2.6.28-Jan8.orig/init/Kconfig
+++ mmotm-2.6.28-Jan8/init/Kconfig
@@ -354,6 +354,15 @@ config CGROUP_DEBUG
 
 	  Say N if unsure
 
+config CGROUP_NOOP
+	bool "No Operation cgroup subsystem"
+	depends on CGROUPS
+	help
+	  This provides cgroup subsystem which has no special features. By
+	  this, you can classify applications freely. That is, you can
+	  classify applications regardless of accounting or control contexts
+	  of the system.
+
 config CGROUP_NS
         bool "Namespace cgroup subsystem"
         depends on CGROUPS

Re: [RFC][PATCH] NOOP cgroup subsystem

[Li Zefan]

KAMEZAWA Hiroyuki wrote:
> How about this idea ? Any comments are welcome.
> 
> -Kame
> 
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> 
> Add an NO OPERATION cgroup subsystem.
> 
> Cgroup itself is providing a feature to attach a task(PID) to some class.
> This feature itself is very useful but "no operation" cgroup is not supported
> now other than debug cgroup. (But debug cgroup should be for DEBUG. distro
> may not configure it.)
> 

Then how can we make sure distro will configure this noop subsys. :)

Or we can make the debug subsys always configured if CONFIG_CGROUP=y ?
The debug system adds no runtime overhead, and it's about 100 lines
of code only.

> Motivation: Simply classify Applications by cgroup
>   When using cgroup for classifying applications, some kind of "control" or
>   "account" subsys must be used. For flexible use of cgroup's nature of
>   classifying applications, NOOP is useful. It can be used regardless of
>   resource accounting unit or name spaces or some controls.
>   IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> 
> After this, application can be checked whether it's still alive or not by
> 
> 	mount -t cgroup none /var/apps noop
> 	mkdir /var/apps/mydaemon
> 	echo 0 > /var/apps/mydaemon
> 	/etc/init.d/mydaemon start
> 	exit
> 
> This can be used as the same technique of "recording pid into /var/run/xxx.pid"
> and not necessary to remove stale files. If mydaemon dies, tasks file will
> be empty and notify_on_release handler can be used.
> 
> I myself want to use this for replacement of "ps -elf | grep" if libcgroup supports
> ps under cgroup.
> 
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Fri, 09 Jan 2009 14:14:55 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> KAMEZAWA Hiroyuki wrote:
> > How about this idea ? Any comments are welcome.
> > 
> > -Kame
> > 
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > 
> > Add an NO OPERATION cgroup subsystem.
> > 
> > Cgroup itself is providing a feature to attach a task(PID) to some class.
> > This feature itself is very useful but "no operation" cgroup is not supported
> > now other than debug cgroup. (But debug cgroup should be for DEBUG. distro
> > may not configure it.)
> > 
> 
> Then how can we make sure distro will configure this noop subsys. :)
> 
I'll ask ;) or set default to y. (because there is almost no overhead.)

> Or we can make the debug subsys always configured if CONFIG_CGROUP=y ?
> The debug system adds no runtime overhead, and it's about 100 lines
> of code only.
> 
I considered that at fist. I wrote this for 2 reasones.
 - Name of "debug" is no suitable for general use.
 - I wonder I can add some more debug support to debug cgroup like fault
   injection. For example,

   Add an create_may_fail file to debug cgroup.
   # echo 1 > debug.create_may_fail

   When create_may_fail is "1", debug->create() will fail at 50% of probability.
   (to make this test more useful, we should move debug_cgroup's subsys id to
    be more higher.)
   I'd like to add this kind of debug feature to debug cgroup when memcg is settled.

-Kame

> > Motivation: Simply classify Applications by cgroup
> >   When using cgroup for classifying applications, some kind of "control" or
> >   "account" subsys must be used. For flexible use of cgroup's nature of
> >   classifying applications, NOOP is useful. It can be used regardless of
> >   resource accounting unit or name spaces or some controls.
> >   IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> > 
> > After this, application can be checked whether it's still alive or not by
> > 
> > 	mount -t cgroup none /var/apps noop
> > 	mkdir /var/apps/mydaemon
> > 	echo 0 > /var/apps/mydaemon
> > 	/etc/init.d/mydaemon start
> > 	exit
> > 
> > This can be used as the same technique of "recording pid into /var/run/xxx.pid"
> > and not necessary to remove stale files. If mydaemon dies, tasks file will
> > be empty and notify_on_release handler can be used.
> > 
> > I myself want to use this for replacement of "ps -elf | grep" if libcgroup supports
> > ps under cgroup.
> > 
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> 

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> Motivation: Simply classify Applications by cgroup
>  When using cgroup for classifying applications, some kind of "control" or
>  "account" subsys must be used. For flexible use of cgroup's nature of
>  classifying applications, NOOP is useful. It can be used regardless of
>  resource accounting unit or name spaces or some controls.
>  IOW, NOOP cgroup allows users to tie PIDs with some nickname.

I agree that the idea is useful. But to me it seems to a bit
artificial that you still have to mount some kind of subsystem purely
to get the grouping, and that you can only have one such grouping.

I think I'd prefer the ability to mount a cgroups hierarchy without
*any* subsystems (maybe with "-o none"?) which would give you a
similar effect, but without you needing to know about a special no-op
subsystem, and would allow you to have multiple "no-op" groupings.

Paul

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Thu, Jan 8, 2009 at 10:24 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
>  - I wonder I can add some more debug support to debug cgroup like fault
>   injection. For example,
>
>   Add an create_may_fail file to debug cgroup.
>   # echo 1 > debug.create_may_fail

Yes, things like that could be potentially very useful for testing.

Paul

Re: [RFC][PATCH] NOOP cgroup subsystem

[Li Zefan]

Paul Menage wrote:
> On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>> Motivation: Simply classify Applications by cgroup
>>  When using cgroup for classifying applications, some kind of "control" or
>>  "account" subsys must be used. For flexible use of cgroup's nature of
>>  classifying applications, NOOP is useful. It can be used regardless of
>>  resource accounting unit or name spaces or some controls.
>>  IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> 
> I agree that the idea is useful. But to me it seems to a bit
> artificial that you still have to mount some kind of subsystem purely
> to get the grouping, and that you can only have one such grouping.
> 
> I think I'd prefer the ability to mount a cgroups hierarchy without
> *any* subsystems (maybe with "-o none"?) which would give you a
> similar effect, but without you needing to know about a special no-op
> subsystem, and would allow you to have multiple "no-op" groupings.
> 

Agreed, but it can't work by just removing the checking in cgroup mount option,
I just tried it:

static int parse_cgroupfs_options(char *data,
				     struct cgroup_sb_opts *opts)
{
	...
-	if (!opts->subsys_bits)
-		return -EINVAL;
	...
}

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Thu, 8 Jan 2009 22:26:46 -0800
Paul Menage <menage@google.com> wrote:

> On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > Motivation: Simply classify Applications by cgroup
> >  When using cgroup for classifying applications, some kind of "control" or
> >  "account" subsys must be used. For flexible use of cgroup's nature of
> >  classifying applications, NOOP is useful. It can be used regardless of
> >  resource accounting unit or name spaces or some controls.
> >  IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> 
> I agree that the idea is useful. But to me it seems to a bit
> artificial that you still have to mount some kind of subsystem purely
> to get the grouping, and that you can only have one such grouping.
> 
> I think I'd prefer the ability to mount a cgroups hierarchy without
> *any* subsystems (maybe with "-o none"?) which would give you a
> similar effect, but without you needing to know about a special no-op
> subsystem, and would allow you to have multiple "no-op" groupings.
> 

Oh, it seems better idea. Then, we need no configs and no additional subsys.
Thank you for a hint. I'll check how I can do it.

Thanks,
-Kame

Re: [RFC][PATCH] NOOP cgroup subsystem

[Daisuke Nishimura]

On Fri, 9 Jan 2009 14:32:26 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> How about this idea ? Any comments are welcome.
> 
I like this :)
It would be very usefull to define a hierarchy just for grouping processes.


Thanks,
Daisuke Nishimura.

> -Kame
> 
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> 
> Add an NO OPERATION cgroup subsystem.
> 
> Cgroup itself is providing a feature to attach a task(PID) to some class.
> This feature itself is very useful but "no operation" cgroup is not supported
> now other than debug cgroup. (But debug cgroup should be for DEBUG. distro
> may not configure it.)
> 
> Motivation: Simply classify Applications by cgroup
>   When using cgroup for classifying applications, some kind of "control" or
>   "account" subsys must be used. For flexible use of cgroup's nature of
>   classifying applications, NOOP is useful. It can be used regardless of
>   resource accounting unit or name spaces or some controls.
>   IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> 
> After this, application can be checked whether it's still alive or not by
> 
> 	mount -t cgroup none /var/apps noop
> 	mkdir /var/apps/mydaemon
> 	echo 0 > /var/apps/mydaemon
> 	/etc/init.d/mydaemon start
> 	exit
> 
> This can be used as the same technique of "recording pid into /var/run/xxx.pid"
> and not necessary to remove stale files. If mydaemon dies, tasks file will
> be empty and notify_on_release handler can be used.
> 
> I myself want to use this for replacement of "ps -elf | grep" if libcgroup supports
> ps under cgroup.
> 
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
>  include/linux/cgroup_subsys.h |    4 ++++
>  init/Kconfig                  |    9 +++++++++
>  kernel/Makefile               |    1 +
>  kernel/cgroup_noop.c          |   34 ++++++++++++++++++++++++++++++++++
>  4 files changed, 48 insertions(+)
> 
> Index: mmotm-2.6.28-Jan8/include/linux/cgroup_subsys.h
> ===================================================================
> --- mmotm-2.6.28-Jan8.orig/include/linux/cgroup_subsys.h
> +++ mmotm-2.6.28-Jan8/include/linux/cgroup_subsys.h
> @@ -59,4 +59,8 @@ SUBSYS(freezer)
>  SUBSYS(net_cls)
>  #endif
>  
> +#ifdef CONFIG_CGROUP_NOOP
> +SUBSYS(noop)
> +#endif
> +
>  /* */
> Index: mmotm-2.6.28-Jan8/kernel/Makefile
> ===================================================================
> --- mmotm-2.6.28-Jan8.orig/kernel/Makefile
> +++ mmotm-2.6.28-Jan8/kernel/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_CGROUP_DEBUG) += cgroup_deb
>  obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
>  obj-$(CONFIG_CPUSETS) += cpuset.o
>  obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
> +obj-$(CONFIG_CGROUP_NOOP) += cgroup_noop.o
>  obj-$(CONFIG_UTS_NS) += utsname.o
>  obj-$(CONFIG_USER_NS) += user_namespace.o
>  obj-$(CONFIG_PID_NS) += pid_namespace.o
> Index: mmotm-2.6.28-Jan8/kernel/cgroup_noop.c
> ===================================================================
> --- /dev/null
> +++ mmotm-2.6.28-Jan8/kernel/cgroup_noop.c
> @@ -0,0 +1,34 @@
> +/*
> + * kernel/cgroup_noop.c - No Operation Cgroup. Just for organizing process tree
> + */
> +
> +#include <linux/cgroup.h>
> +#include <linux/fs.h>
> +#include <linux/slab.h>
> +#include <linux/rcupdate.h>
> +
> +#include <asm/atomic.h>
> +
> +static struct cgroup_subsys_state *noop_create(struct cgroup_subsys *ss,
> +						   struct cgroup *cont)
> +{
> +	struct cgroup_subsys_state *css = kzalloc(sizeof(*css), GFP_KERNEL);
> +
> +	if (!css)
> +		return ERR_PTR(-ENOMEM);
> +
> +	return css;
> +}
> +
> +static void noop_destroy(struct cgroup_subsys *ss, struct cgroup *cont)
> +{
> +	kfree(cont->subsys[noop_subsys_id]);
> +}
> +
> +
> +struct cgroup_subsys noop_subsys = {
> +	.name = "noop",
> +	.subsys_id = noop_subsys_id,
> +	.create = noop_create,
> +	.destroy = noop_destroy,
> +};
> Index: mmotm-2.6.28-Jan8/init/Kconfig
> ===================================================================
> --- mmotm-2.6.28-Jan8.orig/init/Kconfig
> +++ mmotm-2.6.28-Jan8/init/Kconfig
> @@ -354,6 +354,15 @@ config CGROUP_DEBUG
>  
>  	  Say N if unsure
>  
> +config CGROUP_NOOP
> +	bool "No Operation cgroup subsystem"
> +	depends on CGROUPS
> +	help
> +	  This provides cgroup subsystem which has no special features. By
> +	  this, you can classify applications freely. That is, you can
> +	  classify applications regardless of accounting or control contexts
> +	  of the system.
> +
>  config CGROUP_NS
>          bool "Namespace cgroup subsystem"
>          depends on CGROUPS
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Thu, Jan 8, 2009 at 10:29 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>
> Agreed, but it can't work by just removing the checking in cgroup mount option,

Right - it's more complicated than that. There are some places in the
code that rely on the fact that every hierarchy currently has at least
one subsystem (anything that uses find_first_subsystem() for example)
and we'd need to work around that.

Paul

> I just tried it:
>
> static int parse_cgroupfs_options(char *data,
>                                     struct cgroup_sb_opts *opts)
> {
>        ...
> -       if (!opts->subsys_bits)
> -               return -EINVAL;
>        ...
> }
>
>

Re: [RFC][PATCH] NOOP cgroup subsystem

[Li Zefan]

Paul Menage wrote:
> On Thu, Jan 8, 2009 at 10:29 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> Agreed, but it can't work by just removing the checking in cgroup mount option,
> 
> Right - it's more complicated than that. There are some places in the
> code that rely on the fact that every hierarchy currently has at least
> one subsystem (anything that uses find_first_subsystem() for example)
> and we'd need to work around that.
> 

And some other problems, like what's the semantic of /proc/<pid>/cgroup when
using none subsys.

I'm afraid even if it's do-able it might require a lot of changes in cgroup.

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Fri, 09 Jan 2009 14:44:00 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> Paul Menage wrote:
> > On Thu, Jan 8, 2009 at 10:29 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> >> Agreed, but it can't work by just removing the checking in cgroup mount option,
> > 
> > Right - it's more complicated than that. There are some places in the
> > code that rely on the fact that every hierarchy currently has at least
> > one subsystem (anything that uses find_first_subsystem() for example)
> > and we'd need to work around that.
> > 
> 
> And some other problems, like what's the semantic of /proc/<pid>/cgroup when
> using none subsys.
> 
> I'm afraid even if it's do-able it might require a lot of changes in cgroup.
> 
After quick look,
it seems that css_set->subsys==empty case cannot be handled and need much
changes. Maintaining hierarchy tree itself seems difficult.

I think cgroup is being stable day by day. So, I don't like to crash it
by big hummer for this tiny feature.

How about adding "none" subsys  ? (I'd like to set default=y ;)

As Paul said, "Show multiple hierarchy view for each mount point"
seems attractive but it's not very fundametal, IMHO.
If we can increase subsys_id dynamically or subsys can have
multiple root node, the situation will change.

Thanks,
-Kame

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Thu, Jan 8, 2009 at 10:44 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>
> And some other problems, like what's the semantic of /proc/<pid>/cgroup when
> using none subsys.

Since we'd need a way to distinguish between different "no subsys"
hierarchies, we could introduce the idea of a hierarchy name - i.e.
you would mount with options like -onone,name=foo, and this would show
up in /proc/self/cgroup as

name=foo:/path/to/cgroup

You could also name other hierarchies that did have subsystems
mounted, of course. This would allow you to mount existing hierarchies
by name rather than by subsystem set.

Paul

Re: [RFC][PATCH] NOOP cgroup subsystem

[Matthew Helsley]

On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 8 Jan 2009 22:26:46 -0800
> Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
> > >
> > > Motivation: Simply classify Applications by cgroup
> > >  When using cgroup for classifying applications, some kind of "control" or
> > >  "account" subsys must be used. For flexible use of cgroup's nature of
> > >  classifying applications, NOOP is useful. It can be used regardless of
> > >  resource accounting unit or name spaces or some controls.
> > >  IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> > 
> > I agree that the idea is useful. But to me it seems to a bit
> > artificial that you still have to mount some kind of subsystem purely
> > to get the grouping, and that you can only have one such grouping.
> > 
> > I think I'd prefer the ability to mount a cgroups hierarchy without
> > *any* subsystems (maybe with "-o none"?) which would give you a
> > similar effect, but without you needing to know about a special no-op
> > subsystem, and would allow you to have multiple "no-op" groupings.
> > 
> 
> Oh, it seems better idea. Then, we need no configs and no additional subsys.
> Thank you for a hint. I'll check how I can do it.
> 
> Thanks,
> -Kame

	My feeling is this should be a signal subsystem rather than a NOOP
subsystem. Then, if users want the grouping for something besides
signaling, it doesn't matter if they don't issue any signals via the
signal.send file. Also, I think Paul's suggestion would be just as
useful for a signal subsystem.

	What do you think?

Cheers,
	-Matt Helsley

PS: Adding containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org to Cc.

Re: [RFC][PATCH] NOOP cgroup subsystem

[Matthew Helsley]

On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 8 Jan 2009 22:26:46 -0800
> Paul Menage <menage@google.com> wrote:
> 
> > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > >
> > > Motivation: Simply classify Applications by cgroup
> > >  When using cgroup for classifying applications, some kind of "control" or
> > >  "account" subsys must be used. For flexible use of cgroup's nature of
> > >  classifying applications, NOOP is useful. It can be used regardless of
> > >  resource accounting unit or name spaces or some controls.
> > >  IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> > 
> > I agree that the idea is useful. But to me it seems to a bit
> > artificial that you still have to mount some kind of subsystem purely
> > to get the grouping, and that you can only have one such grouping.
> > 
> > I think I'd prefer the ability to mount a cgroups hierarchy without
> > *any* subsystems (maybe with "-o none"?) which would give you a
> > similar effect, but without you needing to know about a special no-op
> > subsystem, and would allow you to have multiple "no-op" groupings.
> > 
> 
> Oh, it seems better idea. Then, we need no configs and no additional subsys.
> Thank you for a hint. I'll check how I can do it.
> 
> Thanks,
> -Kame

	My feeling is this should be a signal subsystem rather than a NOOP
subsystem. Then, if users want the grouping for something besides
signaling, it doesn't matter if they don't issue any signals via the
signal.send file. Also, I think Paul's suggestion would be just as
useful for a signal subsystem.

	What do you think?

Cheers,
	-Matt Helsley

PS: Adding containers@lists.linux-foundation.org to Cc.

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Thu, 15 Jan 2009 18:20:45 -0800
Matthew Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:

> On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 8 Jan 2009 22:26:46 -0800
> > Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> > 
> > > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > > <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
> > > >
> > > > Motivation: Simply classify Applications by cgroup
> > > >  When using cgroup for classifying applications, some kind of "control" or
> > > >  "account" subsys must be used. For flexible use of cgroup's nature of
> > > >  classifying applications, NOOP is useful. It can be used regardless of
> > > >  resource accounting unit or name spaces or some controls.
> > > >  IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> > > 
> > > I agree that the idea is useful. But to me it seems to a bit
> > > artificial that you still have to mount some kind of subsystem purely
> > > to get the grouping, and that you can only have one such grouping.
> > > 
> > > I think I'd prefer the ability to mount a cgroups hierarchy without
> > > *any* subsystems (maybe with "-o none"?) which would give you a
> > > similar effect, but without you needing to know about a special no-op
> > > subsystem, and would allow you to have multiple "no-op" groupings.
> > > 
> > 
> > Oh, it seems better idea. Then, we need no configs and no additional subsys.
> > Thank you for a hint. I'll check how I can do it.
> > 
> > Thanks,
> > -Kame
> 
> 	My feeling is this should be a signal subsystem rather than a NOOP
> subsystem. Then, if users want the grouping for something besides
> signaling, it doesn't matter if they don't issue any signals via the
> signal.send file. Also, I think Paul's suggestion would be just as
> useful for a signal subsystem.
> 
> 	What do you think?
> 

I think
  - Paul's suggestion sounds attractive. But I can't see fundamental differences
    from user's side between "implemented as subsys" and "implemetned as cgroup's
    feature". I feel it's easier for user's cgroup library to handle subsys rather
    than "we can mount it anywhere, multiple times!".
    Flexiblity doesn't means it's easy to use.

  - About signal, there is a problem.
    * cgroup's attach() is per thread.
    * signal is per process.
    To fix this gap, signal subsystem should be implemented as it is with some
    *policy*. This doesn't match simple grouping by NOOP.

  - And, I personally thinks that signal subsystem has to implement following
    controls. (if we implement it.)
    Assume that 
      - we send SIGHUP to all process under /cgroup/group_A/ to restart.
      - we send SIGABRT to tale coredump.
    At doing this kind of things, the user should know the order target and has
    specify order in many cases.
    For example) 
     send signal to one by one  ProcessA -> ProcessB -> ProceessC 
                                or
                                ProcessC -> ProcessB -> ProcessA
     or
       send all at once.
     Which is better is case-by-case.
     (In this area, "freezing" subsystem is also have problems.)



Thanks,
-Kame
    


> Cheers,
> 	-Matt Helsley
> 
> PS: Adding containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org to Cc.
> 
> 

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Thu, 15 Jan 2009 18:20:45 -0800
Matthew Helsley <matthltc@us.ibm.com> wrote:

> On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 8 Jan 2009 22:26:46 -0800
> > Paul Menage <menage@google.com> wrote:
> > 
> > > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > > <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > >
> > > > Motivation: Simply classify Applications by cgroup
> > > >  When using cgroup for classifying applications, some kind of "control" or
> > > >  "account" subsys must be used. For flexible use of cgroup's nature of
> > > >  classifying applications, NOOP is useful. It can be used regardless of
> > > >  resource accounting unit or name spaces or some controls.
> > > >  IOW, NOOP cgroup allows users to tie PIDs with some nickname.
> > > 
> > > I agree that the idea is useful. But to me it seems to a bit
> > > artificial that you still have to mount some kind of subsystem purely
> > > to get the grouping, and that you can only have one such grouping.
> > > 
> > > I think I'd prefer the ability to mount a cgroups hierarchy without
> > > *any* subsystems (maybe with "-o none"?) which would give you a
> > > similar effect, but without you needing to know about a special no-op
> > > subsystem, and would allow you to have multiple "no-op" groupings.
> > > 
> > 
> > Oh, it seems better idea. Then, we need no configs and no additional subsys.
> > Thank you for a hint. I'll check how I can do it.
> > 
> > Thanks,
> > -Kame
> 
> 	My feeling is this should be a signal subsystem rather than a NOOP
> subsystem. Then, if users want the grouping for something besides
> signaling, it doesn't matter if they don't issue any signals via the
> signal.send file. Also, I think Paul's suggestion would be just as
> useful for a signal subsystem.
> 
> 	What do you think?
> 

I think
  - Paul's suggestion sounds attractive. But I can't see fundamental differences
    from user's side between "implemented as subsys" and "implemetned as cgroup's
    feature". I feel it's easier for user's cgroup library to handle subsys rather
    than "we can mount it anywhere, multiple times!".
    Flexiblity doesn't means it's easy to use.

  - About signal, there is a problem.
    * cgroup's attach() is per thread.
    * signal is per process.
    To fix this gap, signal subsystem should be implemented as it is with some
    *policy*. This doesn't match simple grouping by NOOP.

  - And, I personally thinks that signal subsystem has to implement following
    controls. (if we implement it.)
    Assume that 
      - we send SIGHUP to all process under /cgroup/group_A/ to restart.
      - we send SIGABRT to tale coredump.
    At doing this kind of things, the user should know the order target and has
    specify order in many cases.
    For example) 
     send signal to one by one  ProcessA -> ProcessB -> ProceessC 
                                or
                                ProcessC -> ProcessB -> ProcessA
     or
       send all at once.
     Which is better is case-by-case.
     (In this area, "freezing" subsystem is also have problems.)



Thanks,
-Kame
    


> Cheers,
> 	-Matt Helsley
> 
> PS: Adding containers@lists.linux-foundation.org to Cc.
> 
> 

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Fri, 16 Jan 2009 11:45:02 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:

> On Thu, 15 Jan 2009 18:20:45 -0800
> Matthew Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> I think
>   - Paul's suggestion sounds attractive. But I can't see fundamental differences
>     from user's side between "implemented as subsys" and "implemetned as cgroup's
>     feature". I feel it's easier for user's cgroup library to handle subsys rather
>     than "we can mount it anywhere, multiple times!".
>     Flexiblity doesn't means it's easy to use.
I should consider more....

mutiple mount point means that the process can belongs to multiple nickname
groups. oh yes, seems worth to try.


Thanks,
-Kame

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Fri, 16 Jan 2009 11:45:02 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 15 Jan 2009 18:20:45 -0800
> Matthew Helsley <matthltc@us.ibm.com> wrote:
> I think
>   - Paul's suggestion sounds attractive. But I can't see fundamental differences
>     from user's side between "implemented as subsys" and "implemetned as cgroup's
>     feature". I feel it's easier for user's cgroup library to handle subsys rather
>     than "we can mount it anywhere, multiple times!".
>     Flexiblity doesn't means it's easy to use.
I should consider more....

mutiple mount point means that the process can belongs to multiple nickname
groups. oh yes, seems worth to try.


Thanks,
-Kame

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>
>        My feeling is this should be a signal subsystem rather than a NOOP
> subsystem. Then, if users want the grouping for something besides
> signaling, it doesn't matter if they don't issue any signals via the
> signal.send file. Also, I think Paul's suggestion would be just as
> useful for a signal subsystem.

The signal subsystem is similar to the "no-op" subsystem in that
neither of them actually need any state - in principle, it could be
useful to attach a signal subsys to multiple mounted hierarchies, to
provide signal semantics for each of them.

Would it make sense to allow a class of subsystem that explicitly has
no state (or at least, has no state that has a global meaning on the
machine), so that it can be multiply-mounted?

Paul

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley <matthltc@us.ibm.com> wrote:
>
>        My feeling is this should be a signal subsystem rather than a NOOP
> subsystem. Then, if users want the grouping for something besides
> signaling, it doesn't matter if they don't issue any signals via the
> signal.send file. Also, I think Paul's suggestion would be just as
> useful for a signal subsystem.

The signal subsystem is similar to the "no-op" subsystem in that
neither of them actually need any state - in principle, it could be
useful to attach a signal subsys to multiple mounted hierarchies, to
provide signal semantics for each of them.

Would it make sense to allow a class of subsystem that explicitly has
no state (or at least, has no state that has a global meaning on the
machine), so that it can be multiply-mounted?

Paul

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Mon, 19 Jan 2009 17:52:36 -0800
Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

> On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >        My feeling is this should be a signal subsystem rather than a NOOP
> > subsystem. Then, if users want the grouping for something besides
> > signaling, it doesn't matter if they don't issue any signals via the
> > signal.send file. Also, I think Paul's suggestion would be just as
> > useful for a signal subsystem.
> 
> The signal subsystem is similar to the "no-op" subsystem in that
> neither of them actually need any state - in principle, it could be
> useful to attach a signal subsys to multiple mounted hierarchies, to
> provide signal semantics for each of them.
> 
In my understanding, "sending signal" requires some protocol/order in userland.

Assume that users has to send signal in following order
  Application A -> Application B -> Application C.....
and may have problems sending signals in following order
  Application B -> Application A ->.....

So, signal and noop(just classify apps) is not equivalent in this semantics.

> Would it make sense to allow a class of subsystem that explicitly has
> no state (or at least, has no state that has a global meaning on the
> machine), so that it can be multiply-mounted?
> 
multilply-mounted means its own hierachy can be created per mount point ?
If so, signal subsystem can be used instead of noop.

Thanks,
-Kame

Re: [RFC][PATCH] NOOP cgroup subsystem

[KAMEZAWA Hiroyuki]

On Mon, 19 Jan 2009 17:52:36 -0800
Paul Menage <menage@google.com> wrote:

> On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley <matthltc@us.ibm.com> wrote:
> >
> >        My feeling is this should be a signal subsystem rather than a NOOP
> > subsystem. Then, if users want the grouping for something besides
> > signaling, it doesn't matter if they don't issue any signals via the
> > signal.send file. Also, I think Paul's suggestion would be just as
> > useful for a signal subsystem.
> 
> The signal subsystem is similar to the "no-op" subsystem in that
> neither of them actually need any state - in principle, it could be
> useful to attach a signal subsys to multiple mounted hierarchies, to
> provide signal semantics for each of them.
> 
In my understanding, "sending signal" requires some protocol/order in userland.

Assume that users has to send signal in following order
  Application A -> Application B -> Application C.....
and may have problems sending signals in following order
  Application B -> Application A ->.....

So, signal and noop(just classify apps) is not equivalent in this semantics.

> Would it make sense to allow a class of subsystem that explicitly has
> no state (or at least, has no state that has a global meaning on the
> machine), so that it can be multiply-mounted?
> 
multilply-mounted means its own hierachy can be created per mount point ?
If so, signal subsystem can be used instead of noop.

Thanks,
-Kame

Re: [RFC][PATCH] NOOP cgroup subsystem

[Matt Helsley]

On Tue, 2009-01-20 at 12:07 +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 19 Jan 2009 17:52:36 -0800
> Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

<snip>

> > Would it make sense to allow a class of subsystem that explicitly has
> > no state (or at least, has no state that has a global meaning on the
> > machine), so that it can be multiply-mounted?
> > 
> multilply-mounted means its own hierachy can be created per mount point ?

I suspect that's what Paul meant -- multiple, distinct instances of the
subsystem could be mounted.

> If so, signal subsystem can be used instead of noop.

Agreed.

Cheers,
	-Matt Helsley

Re: [RFC][PATCH] NOOP cgroup subsystem

[Matt Helsley]

On Tue, 2009-01-20 at 12:07 +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 19 Jan 2009 17:52:36 -0800
> Paul Menage <menage@google.com> wrote:

<snip>

> > Would it make sense to allow a class of subsystem that explicitly has
> > no state (or at least, has no state that has a global meaning on the
> > machine), so that it can be multiply-mounted?
> > 
> multilply-mounted means its own hierachy can be created per mount point ?

I suspect that's what Paul meant -- multiple, distinct instances of the
subsystem could be mounted.

> If so, signal subsystem can be used instead of noop.

Agreed.

Cheers,
	-Matt Helsley

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Mon, Jan 19, 2009 at 7:07 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
> In my understanding, "sending signal" requires some protocol/order in userland.
>
> Assume that users has to send signal in following order
>  Application A -> Application B -> Application C.....
> and may have problems sending signals in following order
>  Application B -> Application A ->.....

In a case like that, a user would have to do their own signal sending
rather than letting the "signal" subsystem handle it. The signal
subsystem is more useful for doing things like sending less-refined
signals like SIGSTOP or SIGKILL to all tasks in a cgroup.

> multilply-mounted means its own hierachy can be created per mount point ?

Yes.

> If so, signal subsystem can be used instead of noop.

Supporting mounting a subsystem in multiple different hierarchies
would pretty much involve supporting mounting a hierarchy with no
subsystems (at least in the way I envisaged it), so you wouldn't need
any subsystem in that case if you were just trying to do grouping.

Paul

Re: [RFC][PATCH] NOOP cgroup subsystem

[Paul Menage]

On Mon, Jan 19, 2009 at 7:07 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> In my understanding, "sending signal" requires some protocol/order in userland.
>
> Assume that users has to send signal in following order
>  Application A -> Application B -> Application C.....
> and may have problems sending signals in following order
>  Application B -> Application A ->.....

In a case like that, a user would have to do their own signal sending
rather than letting the "signal" subsystem handle it. The signal
subsystem is more useful for doing things like sending less-refined
signals like SIGSTOP or SIGKILL to all tasks in a cgroup.

> multilply-mounted means its own hierachy can be created per mount point ?

Yes.

> If so, signal subsystem can be used instead of noop.

Supporting mounting a subsystem in multiple different hierarchies
would pretty much involve supporting mounting a hierarchy with no
subsystems (at least in the way I envisaged it), so you wouldn't need
any subsystem in that case if you were just trying to do grouping.

Paul