Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:32 UTC (Wed) by fandingo (guest, #67019)
In reply to: Shuttleworth: Losing graciously by Cyberax
Parent article: Shuttleworth: Losing graciously

> However, such situations are not really normal. In particular, changing levels in cgroups hierarchy is not a trivial operation - new subtree might have limits that the subtree which is being moved already exceeds.

That's really a question of policy, though. If the policy says that some processes need to move to /D/E/F, then they need to go there, regardless of what the resource controllers say. (I'd argue that the process should be moved first, and then the resource controller terminates processes to get back into proper configuration. I don't think that it is acceptable to leave a process in the wrong the subtree.)

It's worth noting that systemd-login, which is not PID 1, does the second action today on user login.

> Then they should talk to a some kind of privileged program that can do this. Traditional UNIX used suid programs for that, and it totally makes sense to use something like cgmanager/systemd for this.

If there are acknowledged shortcomings of cgroupfs, shouldn't the API be changed to support all reasonable actions? Why should the kernel keep interfaces that clearly have shortcomings that cannot be resolved without massive API incompatibilities?

Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> That's really a question of policy, though. If the policy says that some processes need to move to /D/E/F, then they need to go there, regardless of what the resource controllers say.
You policy might say that a process can use 100G of RAM, but that's not going to help you if you only have 500Mb. Right now if you try to do this trick the kernel simply kills the over-limit processes.

> If there are acknowledged shortcomings of cgroupfs, shouldn't the API be changed to support all reasonable actions? Why should the kernel keep interfaces that clearly have shortcomings that cannot be resolved without massive API incompatibilities?
Like filesystem interface? Perhaps we should switch to DBUS instead of using open()?

Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:43 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

backwards compatibility would be a reason for keeping poor interfaces, but if you are going to break them, then you need to do so once, not multiple times.

And the new systemd API is just that, a systemd API, by definition it doesn't deal with use cases that don't use systemd.

and the currently proposed single-writer API in known to not support all use cases, so why should it replace the existing API?

Shuttleworth: Losing graciously

Posted Feb 19, 2014 23:59 UTC (Wed) by fandingo (guest, #67019) [Link]

> and the currently proposed single-writer API in known to not support all use cases, so why should it replace the existing API?

You are talking about the Google multi-hierarchy complaint, right? The cgroups maintainers are on record as saying that this is not reasonable, and they intend to eliminate it.

> backwards compatibility would be a reason for keeping poor interfaces

The cgroups developers believe them to be broken, not poor. Plus, they get in the way of fixing cgroups since cgroupfs leaks too many implementation details.