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.
> case will not work and systemd was hoping that for more complex
> configurations and it could rely on cgconfig.
>
> Anyway, I think initial simple modle of defining a namespace for
> persistent groups is fine to begin with. Say something like following
> in default cgconfig.conf file.
>
> namespace {
> cpu = cgconfig;
> cpuacct = cgconfig;
> }
>
> My only concern is that hierarchy is getting deeper and this means more
> overhead for kernel.
Yep, I think we need better planning of hierarchy. I don't see a major
issue at levels up to 5, but deeper than that can become very very
expensive
Balbir
------------------------------------------------------------------------------
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
