Sorry everyone I forgot Plain text this from google. vger and its hate of html. On Mon, Jul 15, 2013 at 1:47 PM, Peter Dolding <oiaohm@xxxxxxxxx> wrote: > > 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 > > -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
