tasks 和 cgroups.procs 是用来管理控制组中的进程的。要把一个进程加入到某个控制组，把 pid 写入到相应目录的 tasks 文件即可。如
# echo 5678 >/cgroup/cpu/rule3001/tasks
就把 5678 进程加入到了 rule3001控制组。那么 tasks 和 cgroups.procs 有什么区别呢？前面说的对“进程”的管理限制其实不够准确。系统对任务调度的单位是线程。在这里，tasks 中看到的就是线程 id。而 cgroups.procs 中是线程组 id，也就是一般所说的进程 id 。将一个一般的 pid 写入到 tasks 中，只有这个 pid 对应的线程，以及由它产生的其他进程、线程会属于这个控制组，原有的其他线程则不会。而写入 cgroups.procs 会把当前所有的线程都加入进去。如果写入 cgroups.procs 的不是一个线程组 id，而是一个一般的线程 id，那会自动找到所对应的线程组 id 加入进去。进程在加入一个控制组后，控制组所对应的限制会即时生效。想知道一个进程属于哪些控制组，可以通过 cat /proc/<pid>/cgroup 查看。
cpu.cfs_period_us 时间周期
cpu.cfs_quota_us 在时间周期内可使用的 cpu 时间
cpu.cfs_quota_us 也是可以大于 cpu.cfs_period_us 的，这主要是对于多核情况。有 n 个核时，一个控制组中的进程自然最多就能用到 n 倍的 cpu 时间。

cpu.rt_period_us
cpu.rt_runtime_us
这两个对应的是实时进程的限制，平时可能不会有机会用到。

cpu.shares 不是限制进程能使用的绝对的 cpu 时间，而是控制各个组之间的配额。
比如
/cpu/cpu.shares : 1024
/cpu/foo/cpu.shares : 2048
那么当两个组中的进程都满负荷运行时，/foo 中的进程所能占用的 cpu 就是 / 中的进程的两倍。如果再建一个 /foo/bar 的 cpu.shares 也是 1024，且也有满负荷运行的进程，那 /、/foo、/foo/bar 的 cpu 占用比就是 1:2:1 。前面说的是各自都跑满的情况。如果其他控制组中的进程闲着，那某一个组的进程完全可以用满全部 cpu。可见通常情况下，这种方式在保证公平的情况下能更充分利用资源。

cpu.stat
nr_periods 219736029
nr_throttled 0
throttled_time 0
nr_periods、nr_throttled 就是总共经过的周期，和其中受限制的周期。throttled_time 就是总共被控制组掐掉的 cpu 使用时间。

7. 用 cgroups 管理IO资源