Single process controlling all cgroups sounds like looking in right direction but wrong solution.

Peter Dolding oiaohm at gmail.com
Mon Jul 15 03:47:58 UTC 2013


I followed the Maintainers File.  https://www.kernel.org/doc/linux/MAINTAINERS
CONTROL GROUPS (CGROUPS)
M:	Paul Menage <menage at google.com>
M:	Li Zefan <lizf at cn.fujitsu.com>
L:	containers at lists.linux-foundation.org
S:	Maintained
F:	include/linux/cgroup*
F:	kernel/cgroup*
F:	mm/*cgroup*


Apparently by your response this might be a bit out of date.  I just read
lwm and *Tejun Heo is not even as a main maintainer.  Listed as a sub part
maintainer.   By the maintainers file discussions should be in *
containers at lists.linux-foundation.org where I sent this.

Tejun Heo please inform if this is still correct.  Its either update this
or tell lwn.net to get your title correct in future.

Serge I am trying to follow policy that is why I posted here in the first
place.

On Mon, Jul 15, 2013 at 1:25 PM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:

> Hi Peter,
>
> Interesting topic.
>
> I think this issue is best discussed on the cgroups at vger.kernel.org
> mailing list.
>
> -serge
>
> Quoting Peter Dolding (oiaohm at gmail.com):
> > NUMA is where the fun starts.   If I wish to adjust a group of processes
> > bound only to a NUMA group of cpus.   It should not be required to
> disrupt
> > other cpus.
> >
> > Init system controlling the cgroups is also sounding trouble.   Why we
> > don't want to write like 1 000 000 different interfaces to talk to
> cgroups.
> >
> > Items like chromuim browser might wish to use cgroups in future to lets
> say
> > contain flash.
> >
> > Best solution to the problems  not a library or in the init system its a
> > form of userspace driver.
> >
> > The userspace driver has the permissions to alter and change cgroups and
> > possible no right todo anything else in final form.
> >
> > Why not part of the init binary.   Lets say you have 1000 processors.
> > And for some reason you are running something that tweaking cgroups a
> > lot.   You don't want to stall all 1000 processes if it not required.
> > Single process could cause this.   What ever in in change of the cgroups
> > has to be massively multi threaded.    Also has to be changeable based on
> > NUMA requirements of the system at times.   You don't want to have to be
> > editing the core of init system or reboot the system just to change the
> > cgroup management system to be more compatible with current hardware.
>  This
> > is again why userspace driver.  You can stop the driver and start another
> > one if required.   While still maintaining the rule of only 1 active at
> any
> > 1 time.  If someone can load a kernel driver any how the can cause hell.
> >
> > Single process is not going to work because this will require stopping
> all
> > cpus.   What is required is single processes/theads.
> >
> > Going the userspace driver solution emulation of the old cgroup system
> > could be pushed into userspace.   So removing old code from the core and
> > allow rejecting of hazard changes to be applied to the old method without
> > having to update kernel every time.
> >
> > If there is an requirement to change the interface in future its less
> > problem.
> >
> > If kbus (kernel dbus) was already done I would be tempted to place this
> as
> > a default feature on the kbus.   This would not be dependant on any
> > particular init system.
> >
> > Since kbus is not ready creating a text device to receive messages for
> now
> > would be a suitable solution in my eyes.
> >
> > Peter Dolding
> > _______________________________________________
> > Containers mailing list
> > Containers at lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/containers
>


More information about the Containers mailing list