How about this idea ? Any comments are welcome.
-Kame
==
From: KAMEZAWA Hiroyuki <[email protected]>
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 <[email protected]>
---
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
KAMEZAWA Hiroyuki wrote:
> How about this idea ? Any comments are welcome.
>
> -Kame
>
> ==
> From: KAMEZAWA Hiroyuki <[email protected]>
>
> 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 <[email protected]>
On Fri, 09 Jan 2009 14:14:55 +0800
Li Zefan <[email protected]> wrote:
> KAMEZAWA Hiroyuki wrote:
> > How about this idea ? Any comments are welcome.
> >
> > -Kame
> >
> > ==
> > From: KAMEZAWA Hiroyuki <[email protected]>
> >
> > 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 <[email protected]>
>
On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
<[email protected]> 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
On Thu, Jan 8, 2009 at 10:24 PM, KAMEZAWA Hiroyuki
<[email protected]> 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
Paul Menage wrote:
> On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> <[email protected]> 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;
...
}
On Thu, 8 Jan 2009 22:26:46 -0800
Paul Menage <[email protected]> wrote:
> On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> <[email protected]> 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
On Thu, Jan 8, 2009 at 10:29 PM, Li Zefan <[email protected]> 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;
> ...
> }
>
>
On Fri, 9 Jan 2009 14:32:26 +0900, KAMEZAWA Hiroyuki <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Paul Menage wrote:
> On Thu, Jan 8, 2009 at 10:29 PM, Li Zefan <[email protected]> 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.
On Fri, 09 Jan 2009 14:44:00 +0800
Li Zefan <[email protected]> wrote:
> Paul Menage wrote:
> > On Thu, Jan 8, 2009 at 10:29 PM, Li Zefan <[email protected]> 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
On Thu, Jan 8, 2009 at 10:44 PM, Li Zefan <[email protected]> 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
On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 8 Jan 2009 22:26:46 -0800
> Paul Menage <[email protected]> wrote:
>
> > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > <[email protected]> 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 [email protected] to Cc.
On Thu, 15 Jan 2009 18:20:45 -0800
Matthew Helsley <[email protected]> wrote:
> On Fri, 2009-01-09 at 15:32 +0900, KAMEZAWA Hiroyuki wrote:
> > On Thu, 8 Jan 2009 22:26:46 -0800
> > Paul Menage <[email protected]> wrote:
> >
> > > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > > <[email protected]> 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 [email protected] to Cc.
>
>
On Fri, 16 Jan 2009 11:45:02 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
> On Thu, 15 Jan 2009 18:20:45 -0800
> Matthew Helsley <[email protected]> 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
On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley <[email protected]> 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
On Mon, 19 Jan 2009 17:52:36 -0800
Paul Menage <[email protected]> wrote:
> On Thu, Jan 15, 2009 at 6:20 PM, Matthew Helsley <[email protected]> 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
On Tue, 2009-01-20 at 12:07 +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 19 Jan 2009 17:52:36 -0800
> Paul Menage <[email protected]> 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
On Mon, Jan 19, 2009 at 7:07 PM, KAMEZAWA Hiroyuki
<[email protected]> 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