Hello, Peter. On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote: > On Wed, Aug 10, 2016 at 06:09:44PM -0400, Johannes Weiner wrote: > > > [ That, and a disturbing number of emotional outbursts against > > systemd, which has nothing to do with any of this. ] > > Oh, so I'm entirely dreaming this then: > > https://github.com/systemd/systemd/pull/3905 > > Completely unrelated. We use centos in the fleet and are trying to control resources in base system which of course requires writeback control and thus cgroup v2. I'm working to solve the use cases people are facing and systemd is a piece of the puzzle. There is no big conspiracy. As Johannes and Chris already pointed out, systemd is a user of cgroup v2, a pretty important one at this point. While I of course care about it having a proper support for cgroup v2, systemd is just picking up the changes in cgroup v2. cgroup v2 design wouldn't be different without systemd. We'll just have something else playing its role in resource management. > Also, the argument there seems unfair at best, you don't need cpu-v2 for > buffered write control, you only need memcg and block co-mounted. ( Everything I'm gonna write below has already been extensively documented in the posted documentation. I'm gonna repeat the points for completeness but if we're gonna start an actually technical discussion, let's please start from the documentation instead of jumping off of an one liner and trying to rebuild the entire argument each time. I'm not sure what you exactly meant by the above sentence and assuming that you're saying that there are no new capabilities gained by cpu controller being on the v2 hierarchy and thus the cpu controller doesn't need to be on cgroup v2? If I'm mistaken, please let me know. ) Just co-mounting isn't enough as it still leaves the problems with anonymous consumption, different handling of threads belonging to different cgroups, and whether it's acceptable to always require blkio to use memory controller. cgroup v2 is what we got after working through all these issues. While it is true that cpu controller doesn't need to be on cgroup v2 for writeback control to work, it misses the point about the larger design issues identified during writeback control work, which can be easily applied to the cpu controller - e.g. accounting cpu cycles spent for packet reception, memory reclaim, IO encryption and so on. In addition, it is an unnecessary inconvenience for users who want writeback control to require the complication of mixed v1 and v2 hierarchies when their requirements can be easily served by v2, especially considering that the only blocked part is trivial changes to expose cpu controller interface on v2 and that enabling it on v2 doesn't preclude it from being used on a v1 hierarchy if necessary. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
