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 I've already sent a patch to make /proc/<pid>/task/<tid>/children available regardless of configuration. --Andy -- 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
