Використання Linux-груп для збалансування продуктивності процесора

У мене є дві двоядерні системи Linux, встановлені за допомогою Linux-груп з відносно недавніми ядрами; в одному працює Debian Squeeze, в другому - Ubuntu 11.04 Natty Narwhal. Я отримав балансування завантаження процесора з групами, які працюють трохи краще в системі 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

Результат - це те, що я сподівався бачити весь час: "високий" процес, що отримує набагато більший відсоток процесора:

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

Пояснення, чому це працює, було б корисним кроком до з'ясування того, чому попередній не надто.

Я отримав початкове пояснення щодо цього тестового випадку від Стефана Сейфріда, який написав документ, з якого взяли цей приклад. Проблема тут полягає в тому, що частини планувальників процесора групи груп завжди спрямовані на те, щоб зайняти будь-який доступний процесор; він ніколи не застосовує жорсткий ліміт, якщо все підходить відразу.

У випадку, коли два процеси (високий і низький тут) працюють на> = 2 ядрах, це просто буде підтримувати високий рівень на одному ядрі, а низький на іншому. Вони обидва будуть працювати весь час, майже на 100% використання, тому що вони можуть це зробити, не потрапляючи в ситуацію, коли планувальник не надає їм достатньо часу на процесор. Планування cpu.share відбувається лише за наявності дефіциту.

У другому випадку обидва процеси прив’язані до одного процесора. Тоді логіка спільного використання процесора повинна зробити щось корисне з відносними номерами cpu.shares, щоб збалансувати їх, і це робить так, як сподівались.

Жорсткі обмеження щодо використання процесора, швидше за все, не з’являться до того моменту, коли не вийде патч CFS Bandwidth Control . У цей момент можливо можливо отримати щось подібне до того, на що я сподівався.