使用Linux cgroup平衡CPU性能

我安装了两个使用带有相对较新内核的Linux cgroup的双核Linux系统。一个正在运行Debian Squeeze，另一个正在运行Ubuntu 11.04 Natty Narwhal。尽管Debian系统的内核较旧，但我在cgroups上的CPU负载平衡要好一些，因此可以达到CPU负载平衡。但这并不适合所有情况，而我要问的是，这两个系统上都有特定的怪异之处。

如果您阅读带有控制组的Linux中的资源管理，则将提供一个示例，说明如何重现该问题。这是Ubuntu版本（以root身份运行）：

cd /sys/fs/cgroup/cpu
    [On Debian Squeeze start at /mnt/cgroups/cpu instead]
mkdir low high
echo 512 > low/cpu.shares
echo 2048 > high/cpu.shares
yes low > /dev/null &
echo $! > low/tasks
yes high > /dev/null &
echo $! > high/tasks
ps -C yes -opid,%cpu,psr,args
    [repeat that a few times]
killall -9 yes

我期望“高”进程比“低”进程分配更多的时间。这个测试用例实际发生的情况总是像这样：

root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
  PID %CPU PSR COMMAND
 3105 88.3   1 yes low
 3106 94.5   0 yes high

时代几乎是平等的。这是我的问题：为什么会这样？

在演示中，通过将每个进程固定到同一CPU可以解决这个问题。其他行来测试：

taskset -c 1 yes high > /dev/null &
echo $! > high/tasks
taskset -c 1 yes low > /dev/null &
echo $! > low/tasks
ps -C yes -opid,%cpu,psr,args
[later, rinse, repeat]
killall -9 yes

结果就是我一直希望看到的结果：“高”进程获得了更高的CPU百分比：

root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
  PID %CPU PSR COMMAND
 3128 83.3   1 yes high
 3129 20.7   1 yes low

解释为什么这种方法行之有效，这将是弄清为什么早期版本也不行的有用步骤。

我已经从Stefan Seyfried那里获得了关于此测试用例的初步解释，他撰写了该示例的论文。这里的问题是cgroup的CPU调度程序部分始终旨在保持任何可用的CPU繁忙。如果一切都可以满足的话，它从来没有强加任何硬性限制。

在两个进程（此处为高和低）在> = 2内核上运行的情况下，一个内核将保持较高状态，而另一个内核将保持较低状态。两者都将始终以接近100％的使用率运行，因为它们可以这样做，而不会遇到调度程序没有在CPU上给它们足够时间的情况。cpu.share调度仅在缺少资源时发生。

在第二种情况下，两个进程都固定到同一CPU。然后，CPU共享逻辑必须对相对的cpu.shares数字做一些有用的事情，以平衡它们，并且按预期进行。

直到CFS带宽控制补丁发布后，才可能出现对CPU使用率的硬性限制。到那时，可能会得到更多我所希望的东西。