[systemd-devel] [HEADSUP] cgroup changes

[Tejun Heo]

Hello,

On Mon, Jun 24, 2013 at 12:24:38PM -0700, Andy Lutomirski wrote:
> Because more things are becoming per cpu without the option of moving
> of per-cpu things on behalf of one cpu to another cpu.  RCU is a nice
> exception.

Hmm... but in most cases it's per-cpu on the same cpu that initiated
the task.  If a given CPU is just crunching numbers and IRQ affinity
is properly configured, the CPU shouldn't be bothered too much by
per-cpu work items.  If there are, please let us know.  We can hunt
them down.

> The functionality I care about is that a program can reliably and
> hierarchically subdivide system resources -- think rlimits but
> actually useful.  I, and probably many other things, want this
> functionality.  Yes, the current cgroup interface is awful, but it
> gets one thing right: it's a hierarchy.

And the hierarchy support was completely broken for many resource
controllers up until only several releases ago.

> I would argue that designing a kernel interface that requires exactly
> one userspace component to manage it and ties that one userspace
> component to something that can't easily be deployed everywhere (the
> init system) is as big a cheat as the old approach of sneaking bad
> APIs in through a filesystem was.

In terms of API, it is firmly at the level of sysctl.  That's it.

While I agree that having a proper kernel API for hierarchical
resource management could be nice.  That currently is out of scope.
We're already knee-deep in shit with the limited capabilities we're
trying to implement.  Also, I really don't think cgroup is the right
interface for such thing even if we get to that.  It should be part of
the usual process/thread model, not this completely separate thing on
the side.

> IOW, please, when designing this, please specify an API that programs
> are permitted to use, and let that API be reviewed.

cgroup is not that API and it's never gonna be in all likelihood.  As
for systemd vs. non-systemd compatibility, I'm afraid I don't have a
good answer.  This is still all in a pretty earlly phase and the
proper abstractions and APIs are being figured out.  Hopefully, we'll
converge on a mostly compatible high-level abstraction which can be
presented regardless of the actual base system implementation.

Thanks.

-- 
tejun