Usando cgroups do Linux para equilibrar o desempenho da CPU

Eu tenho dois sistemas Linux de núcleo duplo instalados usando cgroups Linux com kernels relativamente recentes; um está executando o Debian Squeeze, o outro Ubuntu 11.04 Natty Narwhal. Eu consegui o balanceamento de carga da CPU com o cgroups trabalhando um pouco melhor no sistema Debian, apesar de seu kernel mais antigo. Mas isso não é adequado para tudo, e a singularidade específica que estou perguntando aqui acontece nos dois sistemas.

Se você ler Gerenciamento de Recursos no Linux com Grupos de Controle , fornece um exemplo mostrando como reproduzir o problema. Aqui está a versão do Ubuntu (execute isso como 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

Eu esperava que o processo "alto" fosse alocado mais tempo que o processo "baixo"; o que realmente acontece com este caso de teste é sempre mais assim:

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

Onde os tempos são quase iguais. Aqui está a minha pergunta: por que isso está acontecendo?

Na apresentação, esse problema é mostrado desaparecendo, fixando cada processo na mesma CPU; linhas adicionais para testar se:

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

O resultado é o que eu esperava ver o tempo todo: o processo "alto" obtendo uma porcentagem muito maior da 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

Explicar por que isso funciona seria um passo útil para descobrir por que o anterior também não.

Eu recebi uma explicação inicial sobre esse caso de teste de Stefan Seyfried, que escreveu o artigo em que este exemplo foi retirado. O problema aqui é que as partes do cgroups do planejador de CPU sempre visam manter ocupada a CPU disponível; ele nunca impõe um limite rígido se tudo couber de uma só vez.

No caso de dois processos (alto e baixo aqui) serem executados em> = 2 núcleos, ele continuará alto em um núcleo e baixo no outro. Ambos serão executados o tempo todo, com quase 100% de uso, porque podem fazê-lo sem atingir a situação em que o agendador não lhes dá tempo suficiente na CPU. A programação do cpu.share só acontece se houver uma falta.

No segundo caso, ambos os processos são fixados na mesma CPU. Então a lógica de compartilhamento da CPU precisa fazer algo útil com os números relativos de cpu.shares para equilibrá-los, e isso é o que se espera.

É provável que os limites rígidos de uso da CPU apareçam até depois que o patch do CFS Bandwidth Control for atingido . Nesse ponto, pode ser possível obter algo mais parecido com o que eu estava esperando.