Использование Linux cgroups для балансировки производительности процессора

У меня установлены две двухъядерные системы Linux с использованием Linux cgroups с относительно недавними ядрами; один работает под Debian Squeeze, другой - Ubuntu 11.04 Natty Narwhal. Я получил балансировку нагрузки процессора с помощью cgroups, работающей немного лучше в системе Debian, несмотря на более старое ядро. Но это не подходит для всего, и конкретная странность, о которой я здесь спрашиваю, возникает в обеих системах.

Если вы читаете « Управление ресурсами в 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

Где времена почти равны. Вот мой вопрос: почему это происходит?

В презентации эта проблема показана как устранение путем закрепления каждого процесса на одном и том же процессоре; дополнительные строки для проверки этого:

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

Объяснение, почему это работает, было бы полезным шагом к выяснению, почему предыдущий тоже не работает.

Я получил первоначальное объяснение об этом контрольном примере от Стефана Сейфрида, который написал статью, из которой был взят этот пример. Проблема здесь состоит в том, что части планировщика ЦП в cgroups всегда стремятся держать любой доступный ЦП занятым; это никогда не навязывает жесткий предел, если все будет соответствовать сразу.

В случае, когда два процесса (высокий и низкий здесь) работают на> = 2 ядрах, он будет поддерживать высокий уровень на одном ядре и низкий уровень на другом. Оба будут работать все время, почти на 100%, потому что они могут делать это, не попадая в ситуацию, когда планировщик не дает им достаточно времени на ЦП. Планирование cpu.share происходит только в случае нехватки.

Во втором случае оба процесса закреплены на одном и том же процессоре. Затем логика совместного использования ЦП должна сделать что-то полезное с относительными числами cpu.shares, чтобы сбалансировать их, и она делает это так, как надеялись.

Жесткие ограничения на использование ЦП вряд ли появятся до тех пор, пока не появится патч CFS Bandwidth Control . В этот момент может быть возможно получить что-то более похожее на то, на что я надеялся.