On Mon, Oct 31, 2011 at 10:32:30PM +0100, Lennart Poettering wrote: > On Mon, 31.10.11 14:43, Jan Safranek (jsafr...@redhat.com) wrote: > > > >> Even if there is, then it looks like systemd is better place to manage > > >> it as it already is setting up the whole system and top level > > >> hierarchies. > > >> Thanks to Jason for the suggestion. > > > > Systemd pretty much covers most of the use cases. The main reason to > > keep separate cgconfig is mounting several controllers together in one > > hierarchy - AFAIK systemd won't support this mounting. Still, systemd > > will happily put services to cgroups there. > > We actually do support mounting hierarchies jointly these days. Use > "JoinControllers=" to achieve that. By default we moint and cpu and > cpuacct together. > > > Lennart wrote once on previous discussion [1]: > > > > <cite> > > systemd will create automatic groups for users and services, but will > > not help you to set up any more complex hierarchy then just 1:1 service > > to cgroup mappings. > > > > As soon as you want a more complex tree, with multiple levels or > > something like this you will need something like cgconfig which allows > > you to create any tree you want. > > </cite> > > > > Question is, if we really need complex cgroup hierarchies and/or > > multiple controllers in a hierarchy. > > I am quite sure that sooner or later some folks will need complex cgroup > hierarchies, for example if they want to give a group "teachers" a more > resources than the group "students" or so. I am very sure that some > people want features like that, but I am also quite sure I don't want to > cover that in systemd, which is why I am happy if cgconfig could fill in > that void. I think systemd will cover 90% of the use cases, but the 10% > that are left are valid too, and cgconfig sounds like a useful tool to > make that work.
I think it is little problematic from user's experience point of view. For some things/functionality, go talk to systemd or use its APIs and for rest, go talk to cgconfig/libcgroup. If systemd is managing users, then it should not be too hard to provide a command line to put teacher users in specified cgroups and student users in another specified cgroups. To me cgconfig infrastructure has a big shortcomings that it can only create cgroups and after that it can't enforce anything. One can create "teacher" or "student" cgroups but with a pam plugin, one can't enforce where these sessions are actually run. We tried to compensate for that using pam_cgroup pam plugin. But given the fact that systemd will come with a default policy of putting every user in a cgroup of its own, any user configuration also becomes dicy. One needs to override the default settings of systemd. I think for the sake of better user experience as well as conceptually it makes sense that systemd takes over all the cgconfig functionality. I don't think that leaving 10% use cases to cgconfig and let it remain in a separate subsystem is a good idea. It will conflict with systemd in various interesting ways and user will atbest be confused then who to talk to for what functionality. Especially for me, I am trying to write matahari agent for better cgroup management. Now if a user wants to change default cgroup of a service, who should it talk to. This cgroup agent or to the "service" agent. (There is already a service agent providing basic services like start, stop services etc). Thanks Vivek ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
