[systemd-devel] [HEADSUP] cgroup changes

[Andy Lutomirski]

On Mon, Jun 24, 2013 at 4:19 PM, Tejun Heo <tj at kernel.org> wrote:
> Hello,
>
> On Mon, Jun 24, 2013 at 04:01:07PM -0700, Andy Lutomirski wrote:
>> So what is cgroup for?  That is, what's the goal for what the new API
>> should be able to do?
>
> It is a for controlling and distributing resources.  That part doesn't
> change.  It's just not built to be used directly by individual
> applications.  It's an admin tool just like sysctl - be that admin be
> a human or userland base system.
>
> There's a huge chasm between something which can be generally used by
> normal applications and something which is restricted to admins and
> base systems in terms of interface generality and stability, security,
> how the abstractions fit together with the existing APIs and so on.
> cgroup firmly belongs to the former.  It still serves the same purpose
> but isn't, in a way, developed enough to be used directly by
> individual applications and I'm not even sure we want or need to
> develop it to such a level.

My application is running on a single-purpose system I administer.

I guess what I'm trying to say here is that many systems will rather
fundamentally use systemd.  Admins of those systems should still have
access to a reasonably large subset of cgroup functionality.  If the
single-hierarchy model is going to prevent going around systemd and if
systemd isn't going to expose all of the useful cgroup functionality,
then perhaps there should be a way to separate systemd's hierarchy
from the cgroup hierarchy.

Looking at http://0pointer.de/blog/projects/cgroups-vs-cgroups.html,
it looks like systemd doesn't actually need the cgroup resource
control functionality.  Maybe there's a way to disentangle this stuff.
 The /proc/<pid>/children feature that CRIU added seems like a decent
start.

--Andy