I followed the Maintainers File. https://www.kernel.org/doc/linux/MAINTAINERS CONTROL GROUPS (CGROUPS) M: Paul Menage <menage@xxxxxxxxxx> M: Li Zefan <lizf@xxxxxxxxxxxxxx> L: containers@xxxxxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxx>wrote: > Hi Peter, > > Interesting topic. > > I think this issue is best discussed on the cgroups@xxxxxxxxxxxxxxx > mailing list. > > -serge > > Quoting Peter Dolding (oiaohm@xxxxxxxxx): > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx > > https://lists.linuxfoundation.org/mailman/listinfo/containers > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
