On 09/20/2011 05:28 AM, Balbir Singh wrote:
> On Tue, Sep 20, 2011 at 12:29 AM, Vivek Goyal <vgo...@redhat.com> wrote:
>> On Mon, Sep 19, 2011 at 11:49:26PM +0530, Balbir Singh wrote:
>>> On Mon, Sep 19, 2011 at 11:38 PM, Vivek Goyal <vgo...@redhat.com> wrote:
>>>> On Mon, Sep 19, 2011 at 09:40:33PM +0530, Balbir Singh wrote:
>>>>>>
>>>>>> Ok. That's fine. So then we can maintain some kind of file which has
>>>>>> list of groups created by cgconfig and we try to reclaim those groups
>>>>>> when service is stopped.
>>>>>
>>>>> Namespaces should solve the problem if properly used
>>>>
>>>> Can you elaborate here what do you mean by namespace? I guess you are
>>>> referring to the fact that don't share top level directory between
>>>> systemd and cgconfig and things should be just fine?
>>>>
>>> A namespace allows you to create a config file without a mount section
>>> and adds the namespace (read "path") to all the groups mentioned under
>>> it
>>>
>>> For example, I am using Fedora 15 at the moment and my mount output
>>> for cgroup is
>>>
>>> tmpfs on /sys/fs/cgroup type tmpfs
>>> (rw,nosuid,nodev,noexec,relatime,mode=755)
>>> cgroup on /sys/fs/cgroup/systemd type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
>>> cgroup on /sys/fs/cgroup/cpuset type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,cpuset)
>>> cgroup on /sys/fs/cgroup/cpu type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,cpu)
>>> cgroup on /sys/fs/cgroup/cpuacct type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,cpuacct)
>>> cgroup on /sys/fs/cgroup/memory type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,memory)
>>> cgroup on /sys/fs/cgroup/devices type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,devices)
>>> cgroup on /sys/fs/cgroup/freezer type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,freezer)
>>> cgroup on /sys/fs/cgroup/net_cls type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,net_cls)
>>> cgroup on /sys/fs/cgroup/blkio type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,blkio)
>>> cgroup on /sys/fs/cgroup/perf_event type cgroup
>>> (rw,nosuid,nodev,noexec,relatime,perf_event)
>>>
>>> When I try to mount a set of cgroups and create directories I get an error
>>>
>>> [balbir@balbir libcg]$ sudo cgconfigparser -l /etc/cgconfig.conf
>>> Loading configuration file /etc/cgconfig.conf failed
>>> Cgroup mounting failed
>>>
>>> In the samples directory under src/ you will find namespace_config.conf
>>>
>>> group www {
>>> perm {
>>> task {
>>> uid = root;
>>> gid = root;
>>> }
>>> admin {
>>> uid = root;
>>> gid = root;
>>> }
>>> }
>>> cpu {
>>> cpu.shares = 1000;
>>> }
>>> cpuacct {
>>> }
>>> }
>>>
>>> group ftp {
>>> perm {
>>> task {
>>> uid = root;
>>> gid = root;
>>> }
>>> admin {
>>> uid = root;
>>> gid = root;
>>> }
>>> }
>>> cpu {
>>> cpu.shares = 500;
>>> }
>>> cpuacct {
>>> }
>>> }
>>>
>>> namespace {
>>> cpu = daemons;
>>> cpuacct = daemons;
>>> }
>>>
>>> When I run cgconfigparser -l samples/namespace_config.conf I see
>>> daemons/www and daemons/ftp
>>>
>>> [balbir@balbir libcg]$ ls /sys/fs/cgroup/cpu/daemons/
>>> cgroup.clone_children cgroup.procs cpu.rt_runtime_us ftp
>>> tasks
>>> cgroup.event_control cpu.rt_period_us cpu.shares
>>> notify_on_release www
>>>
>>> [balbir@balbir libcg]$ ls /sys/fs/cgroup/cpu/daemons/
>>> cgroup.clone_children cgroup.procs cpu.rt_runtime_us ftp
>>> tasks
>>> cgroup.event_control cpu.rt_period_us cpu.shares
>>> notify_on_release www
>>>
>>> For other controllers like memory, I don't see these groups because I
>>> did not ask for them in namespace
>>>
>>> [balbir@balbir libcg]$ ls /sys/fs/cgroup/memory/
>>> cgroup.clone_children memory.failcnt
>>> memory.move_charge_at_immigrate memory.stat
>>> notify_on_release
>>> cgroup.event_control memory.force_empty memory.numa_stat
>>> memory.swappiness release_agent
>>> cgroup.procs memory.limit_in_bytes memory.oom_control
>>> memory.usage_in_bytes tasks
>>> libvirt memory.max_usage_in_bytes
>>> memory.soft_limit_in_bytes memory.use_hierarchy
>>>
>>> I hope this clarifies what I was saying, cleanup is an issue, but if
>>> we do cgclear with a clear namespace, it should work out
>>
>> Ok, got it. So basically it is same thing that persistent group live
>> in their own namespace/path and do not share cgroups with systemd. So
>> a hierarchy might look as follows.
>>
>> root
>> / | \
>> system user cgconfig-namespace
>>
>> This should work for most of the setups. But what if a user wants to
>> create a persistent cgroup using cgconfig, allocate resources to it
>> and then ask systemd to launch a service in allocated cgroup. That
>
> Oh! I thought we were speaking of individually managed hierarchies. If
> systemd is to manage the group, it is best to get systemd to create
> it, IMHO.
>
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.
Jan
------------------------------------------------------------------------------
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
