Confused as to the point of this. [LWN.net]

Confused as to the point of this.

Posted Jun 24, 2013 14:27 UTC (Mon) by SEJeff (guest, #51588) [Link] (4 responses)

So if we want to create our own process dependent cgroups, we have to futz systemd to do it? The mkdir() based interface is going away entirely? Hmmmmm... What about tools like cset[1] or libcg[2]? Is systemd going to trounce those? If so, that is going to upset a loooooot of people.

[1] https://code.google.com/p/cpuset
[2] http://libcg.sourceforge.net

Confused as to the point of this.

Posted Jun 24, 2013 15:20 UTC (Mon) by juliank (guest, #45896) [Link]

If they remove the interface, they break existing userspace. What does Linus think about that?

Confused as to the point of this.

Posted Jun 24, 2013 16:25 UTC (Mon) by mezcalero (subscriber, #45103) [Link] (2 responses)

libcgroup will probably not be part of the picture in the long run. In a single-writer scheme there's no room for anybody else changing the tree at all, hence libcgroup's job is basically history then.

Confused as to the point of this.

Posted Jun 24, 2013 21:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Why? I'd really like to be able to create my own subtree and manage it as I see fit. I don't really care how this tree is managed in the global hierarchy.

For example, I might want to run Fedora 19 with systemd in a namespaced container.

Also, how systemd interface is it going to be exposed to containers? Is the attack surface small enough?

Confused as to the point of this.

Posted Jun 25, 2013 18:05 UTC (Tue) by SEJeff (guest, #51588) [Link]

Ok thats fine. What is the answer for HPC users who know how to carve up their resources manually and apply things like CPU isolation/bind numa nodes to specific cpusets? The Linux kernel and systemd can guess right for the 90% use case, but for users who like systemd and still want to carve up the last 10% of their system, how will that be made possible?

I'm just trying to understand what my future will entail as one of those said HPC peeps.

Confused as to the point of this.

Posted Jun 24, 2013 15:31 UTC (Mon) by luto (guest, #39314) [Link]

I've started a subthread on the systemd list. I have an application that needs to do something that should be compatible with a single hierarchy but will be unpleasant to support under systemd's model.

I do think it might be nice if, in the new single-hierarchy regime, systemd could be make to work without cgroups. (Alternative, the cgroup-hierarchy-that-controls-nothing that systemd needs could, perhaps, be allowed to work separately from the real cgroup hierarchy, so systemd could have a mode where it stays away from the latter.)

Confused as to the point of this.

Posted Jun 24, 2013 16:10 UTC (Mon) by sbohrer (guest, #61058) [Link] (2 responses)

This implies a user-kernel ABI change does it not? Are these not forbidden?

Confused as to the point of this.

Posted Jun 24, 2013 16:32 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

Well, the kernel will support the split scheme at the same time as the unified one for some time, so there will be a somewhat "soft" transition. On the systemd side you will be able to tell it to leave the fingers of some controllers and then do you own thing with those controllers. But in the long run OSes which use systemd will have systemd taking possession of all relevant controllers.

This all is gradual thing: the kernel will support split AND unified hiearchies for a time, and so will systemd. Then, systemd will allow other code to change the cgroup fs for some time, but eventually will be more restrictive and log every such change. In the long run on systemd systems we'll enforce single-hierarchy and single-writer strictly.

Confused as to the point of this.

Posted Jun 24, 2013 21:08 UTC (Mon) by khim (subscriber, #9252) [Link]

It's a rule, not law. There are couple of exceptions: even though user-space interfaces are supposed to be maintained forever, they sometimes do change—after a long deprecation period and If there's nobody around to see it, did it really break?

cgroups will obviously follow the slow path

Confused as to the point of this.

Posted Jun 25, 2013 5:24 UTC (Tue) by suckfish (guest, #69919) [Link] (4 responses)

Ugghh. cgroups are a powerful tool for general administration and integration purposes. That's normally done by things like shell scripting, and the hierarchical model exposed & manipulated via the file-system is pretty convenient to access via shell scripting.

I wonder, if cgroups had been single-writer when systemd was conceived, would systemd have been written as the one-and-only single writer or would it have found a way to cooperate more democratically with other users?

Confused as to the point of this.

Posted Jun 25, 2013 5:52 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

single hierarchy != single writer

There's no reason to force a single writer just because they are eliminating the confusion of contradictory hierarchies.

Confused as to the point of this.

Posted Jul 6, 2013 22:22 UTC (Sat) by eternaleye (guest, #67051) [Link] (2 responses)

No. Tejun Heo, the cgroups maintainer, *explicity* wants single-writer - because as he's said, "Cgroup doesn't and will not support delegation of subtrees to different security domains."[1]

[1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6899

Confused as to the point of this.

Posted Jul 6, 2013 22:25 UTC (Sat) by eternaleye (guest, #67051) [Link] (1 responses)

He links to http://thread.gmane.org/gmane.linux.kernel.cgroups/6638 which has some further info. This may be the most damning for what you would like to do, dlang:

* The configurations aren't independent. e.g. for weight-based
controllers, your weight is only meaningful in relation to other
weights at that level. Distributing configuration to whatever
entities which may write to cgroupfs simply cannot work. It's
fundamentally flawed.

That means that anyone could set a stupidly high weight, and starve their peers. You could do double-nesting hacks to isolate that, sure, but that gets painful and stupid very quickly.

Confused as to the point of this.

Posted Jul 6, 2013 22:27 UTC (Sat) by eternaleye (guest, #67051) [Link]

Even worse: You only have that subtree mounted, so you can't see your peers' weights. So you are *actually incapable* of knowing what weights even *would* be 'stupidly high' and starve your peers (or stupidly *low* and starve yourself)