My understanding is that, by default, systemd will start all processes under a single cgroup where cpu.share=1024. If you choose to override the cpu.share for a service, it will create a new cgroup for the processes under that service with cpu.share set to whatever value you've chosen.

I want to manually create a new cgroup with a custom cpu.share that gives me 60% of the CPU. To do that, I need to know the cpu.share values for all existing cgroups. Where is systemd setting these values? Is there an easy way for me to get this? /sys/fs/cgroup/cpu only contains the root group (set to 1024) and the groups I've manually created.


systemd's CGroup options are documented in man systemd.exec (or in man systemd.resource-control). It sounds like the one you are looking for is:

CPUWeight=weight, StartupCPUWeight=weight

Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy is used on the system. These options take an integer value and control the "cpu.weight" control group attribute. The allowed range is 1 to 10000. Defaults to 100. For details about this control group attribute, see cgroup-v2.txt and sched-design-CFS.txt. The available CPU time is split up among all units within one slice relative to their CPU time weight.


My understanding is that, by default, systemd will start all processes under a single cgroup where cpu.share=1024.

I do not believe this is correct. However, please don't take my word as authoritative. Here are the portions of the docs that lead me to this conclusion:

From systemd.resource-control(5):

       Turn on CPU usage accounting for this unit. Takes a boolean argument.
       Note that turning on CPU accounting for one unit might also implicitly
       turn it on for all units contained in the same slice and for all its
       parent slices and the units contained therein. The system default for
       this setting maybe controlled with DefaultCPUAccounting= in systemd-

And also:

   CPUShares=weight, StartupCPUShares=weight
      Those options imply "CPUAccounting=true".

As I read it, if no units have a value set for CPUShares and CPUAccounting is not explicitly enabled anywhere (and DefaultCPUAccounting is not set in system.conf) then systemd may not (will not?) use the cpu hierarchy at all.

(I would welcome any correction on this point.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.