On Tue, 23.08.11 08:10, Vivek Goyal (vgo...@redhat.com) wrote: > > On Mon, Aug 22, 2011 at 08:36:43PM -0700, Dhaval Giani wrote: > > On Mon, Aug 22, 2011 at 7:35 PM, Balbir Singh <bsinghar...@gmail.com> wrote: > > > On Tue, Aug 23, 2011 at 4:13 AM, Dhaval Giani <dhaval.gi...@gmail.com> > > > wrote: > > >> Hi all, > > >> > > >> Lennart just informed me that systemd can now handle mounting > > >> different hierarchies as required by the user (as opposed to a > > >> preconfigured systemd default). With this in mind, I propose to make > > >> cgconfig a lot simpler. Once an official release of systemd is tagged, > > >> we are going to go forward and make cgconfig only handle namespaces > > >> and pre-created groups. At some point the future we should also figure > > >> out how to deprecate cgrulesengd and then we are just remaining with > > >> the core of the library which is soon going to go through a complete > > >> rewrite. > > >> > > > > > > What about non-systemd users? I use upstart from time to time. Can you > > > also elaborate what simpler means? > > > > > > > cgconfig is not to be used to mount cgroup hierarchies. > > If cgconfig is not to be used for mounting cgroup hierarchies then why > did lennart change systemd to accomodate cgconfig specified > configuration?
Hmm? systemd will mount all enabled cgroup controllers at boot, and is now able to mount a couple of them together, if configured so. By default we'll mount everything separately with the exception of "cpu" and "cpuacct" which are mounted together. 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. Or to put this in other words: for systemd services are the focus, and we'll create cgroups for them as one thing among many. In cgconfig cgroups are the focus and how services are ordered into them only secondary. So from my perspective the mounting part of cgconfig is no longer necessary, however the other stuff it does is probably still useful for people who need complex cgroup setups. > > My plan is not > > to do further development of cgconfig except for bugfixes, and in > > general redirect everyone to systemd. At some point in time I would > > also like to remove the mount section of cgconfig.conf. I am looking > > to move to systemd since cgconfig mounting cgroups does not gain any > > advantage. OTOH systemd is in a better position to make decisions on > > where tasks are to go, so I would expect that it is the right place to > > a. mount cgroups > > b. do task classification. > > What about resource allocation to groups. Is lennart willing to provide > cgconfig equivalent interfaces to preconfigure resources allocated > to cgroups. For each service you can configure cgroup attributes. A couple we support with explicit config options, and for the rest there's the generic ControlGroupAttribute= switch which allows to set any kind of attribute desired. How this works in detail is explained here: http://lists.freedesktop.org/archives/systemd-devel/2011-August/003188.html As long as you just want to allocate resources to a specific service systemd covers what you might need. However, if you want to allocate resources to arbitrary cgroups independent of any service then you need something like cgconfig. > I just want to make sure that lennart is in sync and agrees with taking > over the functionality provided by libcgroup. Last time I talked to > him, he was of the opinion that I just want to pick some sane defaults > for systemd and let libcgroup still do its work and he did not propose > to take over resource allocation and task classification functionality > of libcgroup. Yes and I still am of the opinion: I want systemd to cover the 90% of the uses where tehre's a 1:1 mapping between cgroup and service. And for the rest, the more complex hierarchies I want cgconfig to be used. If by task classification you are referring to cgrulesd, then uh oh, i belive that this daemon is inherently broken and should be phased out. The fact that it asynchronously applies cgroups limits is unfixably broken. Lennart -- Lennart Poettering - Red Hat, Inc. ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
