On Mon, Oct 14, 2019 at 02:42:03PM -0600, Tom Hromatka <tom.hroma...@oracle.com> wrote: > This may get long - my apologies up front :). Thanks for your sharing your motivation and the explanations.
> 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. That sounds quite ambitious and I find it definitely challenging. In my opinion, there are (at least) three views on this topic: 1) Where This specifies what controllers are involved and what is the hierarchy built. libcg should either restrict access to systemd-"owned" controllers or should be modified to be able to work under non-root cgroup(s). The tentative plural in the last sentence is getting at another friction surface, pre-systemd users of cgroup may rely on multiple orthogonal hierarchies, that is hardly maskable by the abstraction layer. Such compatibility is better broken (IMO). 2) Who Any systemd-wide classification done by libcg is just asking for problems when systemd assumes potentially different distribution of processes into cgroups. I.e. it should again be restricted to subtrees or controllers. 3) What The attributes that are being tuned/information that is being read about cgroups. This seems relatively trivial involving some translations/mappings. > 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. The upside is that systemd is widely deployed and has active community so these are likely identified quickly. OTOH, I see the benefit of libcg in environments without systemd (e.g. some containers). > 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. As I drafted above, the way to avoid the conflict is to be complementary. I wonder if you considered anything different. Michal _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
