User: Password:
|
|
Subscribe / Log in / New account

All About the Linux Kernel: Cgroup's Redesign (Linux.com)

All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Posted Aug 16, 2013 19:46 UTC (Fri) by hnaz (subscriber, #67104)
In reply to: All About the Linux Kernel: Cgroup's Redesign (Linux.com) by Cyberax
Parent article: All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Nobody is replacing the filesystem interface. The problem is just that because it IS a filesystem interface, people added knobs and exported information like there is no tomorrow. We would never have been this reckless with system calls even though both are unchangeable ABI.

While the rework of the cgroups interface is coordinated with systemd people, cgroups won't be based on or depend on systemd.

Cgroups are going to be more consistent across controllers and they are going to assume a single agent setting up and administrating a group (could be systemd, could be your custom management script, could be you from the shell). There is a ton of cruft in the code that bends over backwards to support multiple users accessing the control and info knobs _at the same time_ but nobody is doing that anyway.

You can still delegate if you like, but delegate to a single entity.


(Log in to post comments)

All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Posted Aug 16, 2013 20:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Nobody is replacing the filesystem interface.
They do (by switching to the 'single writer' model). And that's the problem.

> While the rework of the cgroups interface is coordinated with systemd people, cgroups won't be based on or depend on systemd.
Yeah, sure. Right now cgroups do whatever systemd people want, and damn the consequences.

> Cgroups are going to be more consistent across controllers and they are going to assume a single agent setting up and administrating a group (could be systemd, could be your custom management script, could be you from the shell).
Yeah, so there'll be no way for my user processes to setup their own cgroups.

And I actually DO use this. For example, I have a 'deeptime' utility to get the accurate runtime for a process tree which works by creating a cpuacct cgroup.

>There is a ton of cruft in the code that bends over backwards to support multiple users accessing the control and info knobs _at the same time_ but nobody is doing that anyway.
I understand, it's better if nobody (or only systemd, as a concession) has access to cgroups.

Also, somehow, /proc and /sys filesystems work without single entities controlling access to them.

> You can still delegate if you like, but delegate to a single entity.
How? And what if I don't WANT a single entity?

Don't get me wrong, I'm all for general cgroups interface cleanups. There are lots of missing or inconsistent features (there's no way to get notifications when cgroup becomes empty, for example). Multiple tree structure also complicates things - I totally understand that. IMO, merging blkio and memory controller totally makes sense.

But then we have freezer controller and cpuacct. I fail to see how merging them into the single controller would help. There are no places in the kernel where it's unclear if a resource should belong to cpuacct/freezer or to some other controller (like in the case of blkio and memcg). So why are they being merged?

For example, right now I'm using cpuacct to measure time spent in various kinds of processes (i.e. 10 cpu-seconds were spent in 'make', 20 cpu-seconds were spent in 'bash', etc). How am I going to do this with single cgroups, assuming that I need to gather statistics across several memcg system partitions?

Then there's freezer controller - we use it to atomically pause a graph of dependent processes (e.g. a Postgres database and its clients) in case of low-memory conditions. How are we going to do this with the single tree model?

So yes, I see that the development of cgroups follows the usual fouled-up course of previous cgroups development. Second-system syndrome in full force.

All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Posted Aug 17, 2013 8:52 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

See, now you've done it. By opening with a trollish statement, nobody replies to your actual description of the problems you have - you got yourself ignored.

And as innocent bystander who's always interested in following debates like these, I'm deprived from a reply just as you are ;-)

Yet I totally understand that you started with that statement - I did the same two days ago and now nobody listens to my legitimate complaints about $SUBJECT anymore :D

All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Posted Aug 17, 2013 6:17 UTC (Sat) by Rudd-O (guest, #61155) [Link]

Thank you. Cyberax has been persistently spreading disinformation and outright lies about what's going to happen. These people are toxic.

All About the Linux Kernel: Cgroup's Redesign (Linux.com)

Posted Aug 17, 2013 10:41 UTC (Sat) by jubal (subscriber, #67202) [Link]

You might want to actually read what he wrote before you start to denigrate him; ritually repeating phrases about FUD, misinformation and toxicity does not award you any points (and makes you look like a toxic personality, mind).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds