On Tue, Sep 20, 2011 at 02:20:27PM +0530, Balbir Singh wrote: > On Tue, Sep 20, 2011 at 1:32 PM, Jan Safranek <jsafr...@redhat.com> wrote: > > On 09/20/2011 09:31 AM, Balbir Singh wrote: > >>> > >>> No, as Lennart stated earlier in this thread, systemd is limited to > >>> create only simple hierarchies, for complex ones cgconfig should be used > >>> to create and configure groups for services. So systemd and cgconfig > >>> should cooperate in shared cgroup trees, they won't have separate > >>> subtrees. > >>> > >> > > I was responding to Vivek's comments and so primarily addressing his concern > > > If this is the case, 'cgconfig start' should track the cgroups it > > created, so 'cgconfig stop' knows, what to remove. This means both > > cgconfigparser and cgclear needs to be changed to write/read the > > tracklog to/from /var or /run (TBD). 'cgconfig restart' would naturally > > delete only empty groups (like 'stop') > > > I agree we need to cooperate on the shared cgroup trees, but that > requires some fundamental changes like > > 1. Namespaces can be used to create the hierarchy
I think using namespaces to make sure that we don't have shared cgroups between cgconfig and systemd, should solve 90% of the problems. For rest 10%, we need to make sure we are able to handle the case of shared cgroups. > > at run time we need > > 1. Notification when a cgroup gets created (deletion we already got > it, but we might need client specific notification) Why do we need notification when cgroup is created. cgconfig can just create cgroup if it is not there otherwise somebody else created the cgroup and just set the user specified policies on it. (File permissions, controller weights etc). > > I am not sure what sort of pluggable policy would help us integrate > with systemd, I guess we need systemd aware config files when the > administrator is running with a system that has systemd. > > What else does everybody have in mind? I think to begin with we can just keep it simple. Do not return error if cgroup already exists. Mark it sticky so that systemd does not remove it. During cgconfig service stop, do not remove a cgroup if there are tasks in it. Anything more complicated then this, might not be required in practice. Thanks Vivek ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
