2019-06-12 14:52:41 -03:00
=========================
2008-11-10 20:41:13 +05:30
CPU Accounting Controller
2019-06-12 14:52:41 -03:00
=========================
2008-11-10 20:41:13 +05:30
The CPU accounting controller is used to group tasks using cgroups and
account the CPU usage of these groups of tasks.
The CPU accounting controller supports multi-hierarchy groups. An accounting
group accumulates the CPU usage of all of its child groups and the tasks
directly present in its group.
2019-06-12 14:52:41 -03:00
Accounting groups can be created by first mounting the cgroup filesystem::
2008-11-10 20:41:13 +05:30
2019-06-12 14:52:41 -03:00
# mount -t cgroup -ocpuacct none /sys/fs/cgroup
2011-06-15 12:59:45 -07:00
With the above step, the initial or the parent accounting group becomes
visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in
the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
/sys/fs/cgroup/cpuacct.usage gives the CPU time (in nanoseconds) obtained
by this group which is essentially the CPU time obtained by all the tasks
2008-11-10 20:41:13 +05:30
in the system.
2019-06-12 14:52:41 -03:00
New accounting groups can be created under the parent group /sys/fs/cgroup::
2008-11-10 20:41:13 +05:30
2019-06-12 14:52:41 -03:00
# cd /sys/fs/cgroup
# mkdir g1
# echo $$ > g1/tasks
2008-11-10 20:41:13 +05:30
The above steps create a new group g1 and move the current shell
process (bash) into it. CPU time consumed by this bash and its children
can be obtained from g1/cpuacct.usage and the same is accumulated in
2011-06-15 12:59:45 -07:00
/sys/fs/cgroup/cpuacct.usage also.
2009-03-31 10:02:22 +05:30
cpuacct.stat file lists a few statistics which further divide the
CPU time obtained by the cgroup into user and system times. Currently
the following statistics are supported:
user: Time spent by tasks of the cgroup in user mode.
system: Time spent by tasks of the cgroup in kernel mode.
user and system are in USER_HZ unit.
cpuacct controller uses percpu_counter interface to collect user and
system times. This has two side effects:
- It is theoretically possible to see wrong values for user and system times.
This is because percpu_counter_read() on 32bit systems isn't safe
against concurrent writes.
- It is possible to see slightly outdated values for user and system times
due to the batch processing nature of percpu_counter.