[systemd-devel] Systemd and cgroup management (and libcgroup)

[Jan Safranek]

On 10/18/2011 10:50 PM, Vivek Goyal wrote:
> On Tue, Oct 18, 2011 at 04:45:59PM -0400, Vivek Goyal wrote:
>> Hi,
> 
> Oops, got old addresses of dhaval and bablir. Fixing it. Please reply 
> to this mail instead of previous one.
> 
> Thanks
> Vivek
> 
>>
>> We have talked a lot of about libcgroup and systemd in the past and when I 
>> thought that debate is settled, here comes some more things to discuss.
>>
>> Previously libcg was doing cgroup management and now sytemd is taken over
>> a lot of it.
>>
>> - Creation of hierarchies. Taking control of hierarchies have taken away
>>   part of the cgconfig functionality.
>>
>> - Providing automatic cgroups for users has taken away part of the
>>   functionality provided by cgroup pam plugin.
>>
>> - Providing automatic cgroups for services has taken away the service
>>   management which in the past potentially could be done with the help
>>   of cgconfig.
>>
>> Now systemd is managing services and users from cgroup point of view
>> which past init system never did and that was part of the reason to
>> have pam_cgroup plugin and cgconfig. Given the fact that new init
>> system has taken over a lot of cgroup management, few things come
>> to mind.
>>
>> - Should systemd provide a way to change default cgroups of users as it
>>   provides for services.
>>
>> - Should systemd provide a way to change default resources of cgroups of
>>   users as it provides for services.
>>
>> - cgroup and associated resources now become properties of objects being
>>   managed by systemd (services and users). To me it will make sense
>>   to provide an API so that an application can call into those APIs
>>   and manage it. 
>>
>>   Should systemd provide an API to manage cgroups and resources of cgroups
>>   of services and users it is managing.
>>
>>   Lennart, I know you had said that editing the unit file is an API,
>>   but a real will API will help.
>>
>> Should cgconfig equivalent functionality be owned by systemd
>> -----------------------------------------------------------
>> This is contentious one and I think there are two parts to it.
>>
>> - Is cgconfig really needed. What are the use cases given the fact that
>>   systemd now takes care of setting up the system.
>>
>> - If cgconfig is needed, then who should really manage it. systemd or
>>   libcg.
>>
>> I am finding it hard to think of any good use cases of cgconfig now given
>> the fact systemd has taken over service and user management. What else is
>> left out. Everything is children of either user sessions of services
>> and they should manage their own children cgroups. Where's the need
>> of statically defining cgroups and resources and what will be launched
>> in those.
>>
>> 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.

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.


Jan

[1]: http://thread.gmane.org/gmane.comp.lib.libcg.devel/3257/focus=3267