Messages in this thread | | | Date | Fri, 28 Jun 2013 12:18:38 -0700 | From | Andy Lutomirski <> | Subject | Re: cgroup: status-quo and userland efforts |
| |
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
| |