Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx): > On 06/27/2013 11:01 AM, Tejun Heo wrote: > > AFAICS, having a userland agent which has overall knowledge of the > > hierarchy and enforcesf structure and limiations is a requirement to > > make cgroup generally useable and useful. For systemd based systems, > > systemd serving that role isn't too crazy. It's sure gonna have > > teeting issues at the beginning but it has all the necessary > > information to manage workloads on the system. > > > > A valid issue is interoperability between systemd and non-systemd > > systems. I don't have an immediately good answer for that. I wrote > > in another reply but making cgroup generally available is a pretty new > > effort and we're still in the process of figuring out what the right > > constructs and abstractions are. Hopefully, we'll be able to reach a > > common set of abstractions to base things on top in itme. > > > > The systemd stuff will break my code, too (although the single hierarchy > by itself won't, I think). I think that the kernel should make whatever > simple changes are needed so that systemd can function without using > cgroups at all. That way users of a different cgroup scheme can turn > off systemd's. > > Here was my proposal, which hasn't gotten a clear reply: > > http://article.gmane.org/gmane.comp.sysutils.systemd.devel/11424 Neat. I like that proposal. > I've already sent a patch to make /proc/<pid>/task/<tid>/children > available regardless of configuration. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
