Single process controlling all cgroups sounds like looking in right direction but wrong solution.
serge.hallyn at ubuntu.com
Mon Jul 15 03:25:51 UTC 2013
I think this issue is best discussed on the cgroups at vger.kernel.org
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
> 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
More information about the Containers