lkml.org 
[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] NOOP cgroup subsystem
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.
>
>



\
 
 \ /
  Last update: 2009-01-16 03:49    [W:0.088 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site