[systemd-devel] [PATCH] core: add startup resource control option

WaLyong Cho walyong.cho at samsung.com
Thu Apr 24 09:41:30 PDT 2014


On 04/24/2014 06:15 AM, Lennart Poettering wrote:
> On Wed, 26.03.14 00:12, WaLyong Cho (walyong.cho at samsung.com) wrote:
> 
>>
>> On 03/25/2014 05:01 AM, Lennart Poettering wrote:
>>> On Tue, 25.03.14 01:03, WaLyong Cho (walyong.cho at samsung.com) wrote:
>>>
>>>>          /* Figure out which controllers we need */
>>>>  
>>>> -        if (c->cpu_accounting || c->cpu_shares != 1024)
>>>> +        if (c->cpu_accounting ||
>>>> +            c->startup_cpu_shares != 1024 ||
>>>> +            (manager_state(m) != MANAGER_STARTING && c->cpu_shares !=
>>>> 1024))
>>>
>>> This looks incorrect. Shouldn't it be like this:
>>>
>>> ...
>>>
>>> if (c->cpu_accounting ||
>>>     (manager->state(m) == MANAGER_STARTING ? c->startup_cpu_shares : c->cpu_shares) != 1024)
>>>
>>
>> At previous patch, I also wrote similar with your thought. Assume, some
>> of units just only specified StartupCPUShares=(or
>> StartupBlockIOWeight=). In this case, that unit will not be changed to
>> default weight because global state is already changed to running. So I
>> put startup_cpu_shares condition alone.
> 
> No sure I understand. The service processes should be removed from the
> CPU cgroup as soon as the global state reaches RUNNING if only
> CPUShares= is set, but StartupCPUShares= isn't? Hence the startup cpu
> shares value should not have an effect anymore. Am I missing something?
>

If I quote part of the commit message:
only assign the specified weight during startup state. If not CPUShares= or
BlockIOWeight= be specified, then the attribute is re-assigned to each
default attribute value.

This means if a service specified only "StartupCPUShare=" and has
started with some of special cpu.shares. And systemd state is changed to
running then cpu.shares of the service should be changed to default(1024).
(I think this is make sense.)
To do this, *cgroup_context_get_mask* have to detect the mask when only
startup is set as NOT default(1024).

see this my test.

I made two services:

   -bash-4.2# cat delay.service
   [Unit]
   Description=delay
   Before=default.target

   [Service]
   Type=oneshot
   ExecStart=/bin/sleep 20

   [Install]
   WantedBy=multi-user.target



   -bash-4.2# cat blabla.service
   [Unit]
   Description=blabla

   [Service]
   ExecStart=/bin/sleep 120
   StartupCPUShares=700

   [Install]
   WantedBy=multi-user.target

And enabled both. and reboot.



-bash-4.2# dbus-send --system --print-reply
--dest=org.freedesktop.systemd1 /org/freedesktop/systemd1
org.freedesktop.DBus.Properties.Get
string:org.freedesktop.systemd1.Manager string:SystemState;cat
/sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares
method return sender=:1.1 -> dest=:1.7 reply_serial=2
   variant       string "starting"
700

blabla service successfully set as 700 cpu.shares.



-bash-4.2#
-bash-4.2# dbus-send --system --print-reply
--dest=org.freedesktop.systemd1 /org/freedesktop/systemd1
org.freedesktop.DBus.Properties.Get
string:org.freedesktop.systemd1.Manager string:SystemState;cat
/sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares
method return sender=:1.1 -> dest=:1.8 reply_serial=2
   variant       string "running"
1024

After startup had finished then the blabla service was set as
default(1024) value.



-bash-4.2# cat
/sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares
cat:
/sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares:
No such file or directory

And after two minutes later, the blabla service was finished. So the
cgroup was disapeared.


Thanks,
WaLyong

>
> Lennart
> 


More information about the systemd-devel mailing list