On 10/14/19 10:30 AM, Michal Koutný wrote:
Hello Tom, I see your efforts around covering libcgroup with tests, I assume from earlier conversations it is because of adding support for cgroup v2.
Yes, that's correct.
From my experience, usage of libcgroup is often in direct conflict with systemd maintaining the hierarchy. I.e. for users it is more convenient to go through systemd provided APIs currently or they should be confined to a hierarchy given up by systemd (e.g. delegated subtree). I consider libcgroup operating on lower level than systemd's abstractions, i.e. it'd need some extra work to hide the v1 vs v2 differences from its users or the users should be aware of the differences anyway.
Agreed. I think you have written up an excellent summary of the differences between systemd and libcgroup.
I'm wrapping my head around what would v2 support bring and how it combines with the systemd hierarchy.
Great question. I'll try and answer it in the two questions you raised below.
Hence I'd like to ask (I'm interested in opinions from anyone one the list): - What is the vision/extent of the proposed changes?
This may get long - my apologies up front :). Several teams within Oracle are using cgroups and have expressed interest in some of the features of cgroups v2 - arguably a better API, pressure stall information (PSI), and newer features, etc. (There is a mixture of usage styles among the teams - some are using libcgroup, some sysfs directly, and a little bit of systemd.) But migrating to cgroups v2 is challenging for nearly all of these teams because they have _very_ long product cycles - 10+ years in some cases. In fact, we are still supporting Oracle Linux from 2011; it consists of kernel 2.6.39, System V, and cgroup v1 only. Several Oracle applications have similarly long lifecycles. Whatever solution we come up with, these apps will be running on cgroup v1-only systems, cgroup v1/v2 systems, and cgroup v2-only systems. Two requirements have consistently been raised across all of these teams: 1. Abstract away the cgroups v1 vs. v2 differences 2. The abstraction layer needs to be supported for a very long time and easy to backport fixes/features into. A 10-year support cycle is likely I initially looked into extending and improving the systemd cgroups logic, but quickly ran into challenges. Ignoring the fact that Oracle still supports a kernel release and apps that are on System V, there are a few difficulties in using systemd as the abstraction layer. Oracle has several iterations of systemd that are in long term support, and their codebases differ significantly. This would make backporting fixes and features difficult, as each release may require its own custom patch. Also, some customers had concerns about embedding the abstraction code directly into systemd. A bug in systemd could render a system unbootable, and thus they were afraid of putting a new feature in the large and complex codebase of systemd. So this led us to pursue updating and improving libcgroup. Yes, there are potential conflicts with systemd, but I believe we can safely mitigate them.
- What are intended use cases of such an extension?
As mentioned in my ramblings above, teams within Oracle want to be able to utilize the same application (again with a long product lifecycle) on systems that are cgroups v1-only, cgroups v1/v2, and cgroups v2-only. My current plan is as follows: 1. Add test framework and automation around existing libcgroup codebase [LARGELY DONE] 2. Add tests around existing libcgroup v1 code [TODO] 3. Add cgroup v2 support (and plenty of tests) [TODO] 4. Start working on an abstraction layer to hide the v1/v2 differences. LXD and systemd have done some work here, and I hope to leverage/learn from them [TODO] Thanks so much for your interest and your help so far. I would love to hear your thoughts on how we can make this better. Thanks. Tom PS - I presented this exact topic at Linux Plumbers Conference in Lisbon this year [1]. (Alas there is no recording.) Other companies also expressed interest in an abstraction layer and have offered to provide requirements and API assistance. [1] https://www.linuxplumbersconf.org/event/4/contributions/524/
Thanks, Michal
_______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
