Date:	Fri, 16 Jan 2009 11:45:02 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	matthltc@...ibm.com
Cc:	Paul Menage <menage@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lizf@...fujitsu.com" <lizf@...fujitsu.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFC][PATCH] NOOP cgroup subsystem

On Thu, 15 Jan 2009 18:20:45 -0800
Matthew Helsley <matthltc@...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@...gle.com> wrote:
> > 
> > > On Thu, Jan 8, 2009 at 9:32 PM, KAMEZAWA Hiroyuki
> > > <kamezawa.hiroyu@...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@...ts.linux-foundation.org to Cc.
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists