Skip to content

CPUAccounting=yes unnecessarily enables the expensive CPU controller #9650

@ghost

Description

Is your feature request related to a problem? Please describe.

Assume the unified cgroup controller. Recent linux kernels (e.g., 4.16.16) allow us to use CPU accounting without enabling CPU controller. For example see the following transcript:

# systemd-run --user --wait -t --unit=foo -p "CPUAccounting=yes" bash
Running as unit: foo.service
Press ^] three times within 1s to disconnect TTY.
# cat /sys/fs/cgroup/user.slice/user-0.slice/user@0.service/foo.service/cpu.stat 
usage_usec 38558
user_usec 8568
system_usec 29990
# cat /sys/fs/cgroup/user.slice/user-0.slice/user@0.service/foo.service/cgroup.controllers 
memory pids

CPU Accounting is available without enabling the CPU controller. Actually, upon the completion of bash, systemd-run showed

Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 2min 52.760s
CPU time consumed: 45ms

CPU accounting information is also shown by systemctl --user status foo.service. But CPUAccounting=yes generally enables the costly CPU controller. It is probably unnecessary and waste of system resource. This RFE is an inverse of 9647 in some sense.

Describe the solution you'd like

  • Make CPUAccounting=yes independent of enablement the costly CPU resource controller (on recent Linux kernels).

  • If CPU accounting is less expensive/costly than enablement of CPU controller, please consider DefaultCPUAccounting=yes (on recent Linux kernels).

Describe alternatives you've considered

I am sorry if my understanding is insufficient.

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFE 🎁Request for Enhancement, i.e. a feature requestcgroupspid1

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions