一：概述
对于linux autogroup的作用，很多同学可能是听说过，但，并未验证过。
考虑下面场景，开两个terminal，T1和T2，在T1中运行进程P1，P1开启9个线程编译代码，在T2中运行进程P2，P2开启1个线程编译代码，那么，在top命令中查看cpu使用率时，P1和P2各占据 多少CPU呢？
我们的期待是：
1. 当未开启linux autogroup时，P1 90%，P2 10%
2. 当已开启linux autogroup时，P1 50%，P2 50%
让我们使用下面的配置来进行验证
marvin@vm:~$ uname -a
Linux vm 6.5.0-28-generic #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 14:39:20 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
marvin@vm:~$
二：autogroup不符合预期
1. 未开启linux autogroup时，如下所示。确实 h1 90%, h2 10%。符合预期。
2. 已开启linux autogroup时，如下图所示，很不幸，依然是 h1 90%, h2 10%。不符合预期。
三：不符合预期的直接原因
在已开启linux autogroup的情况下，为什么CPU并未均分呢？从下图可以看到，无论是否开启autogroup，h1和h2的 "cpu,cpuacct" 都位于 /user.slice这个cgroup下面。
而，sched(7) - Linux manual page根据autogroup文档，进程只有当位于root cgroup下时，autogroup才会起作用。
四：放入root cgroup，则一切符合预期
于是，我们开启autogroup，然后，启动进程h1和h2，然后，我们将两个进程都移动进root cgroup中。
果然看到效果啦，h1 9个线程，h2 1个线程，但，两者确实平分CPU的。很好，符合预期啦。
还需要注意到：
如果一开始autogroup是开启的，然后，我们将进程移动到root cgroup，于是，h1和h2各占50% CPU。
如果一开始autogroup是关闭的，然后，我们将进程移动到root cgroup，然后，我们再打开autogroup，此时，autogroup依然是无效的。（也就说，动态修改autogroup后，已移动进root cgroup中的进程 依然不会按着 开启autogroup 执行）。
五：systemd的原因？
为什么在不同terminal中运行的进程，却位于user.slice中呢？这应该是systemd的原因，当有了systemd之后，autogroup应该是无法起作用了，systemd会将terminal启动的进程都放置到user.slice中（而不是root cgroup）。但，具体为什么会这样，不知道，后面研究吧！