Utilisation de groupes de contrôle Linux pour équilibrer les performances du processeur

J'ai deux systèmes Linux dual-core installés à l'aide de groupes de contrôle Linux avec des noyaux relativement récents; l'un exécute Debian Squeeze, l'autre Ubuntu 11.04 Natty Narwhal. J'ai obtenu un équilibrage de la charge CPU avec des groupes de contrôle fonctionnant un peu mieux sur le système Debian malgré son noyau plus ancien. Mais ce n'est pas bon pour tout, et la bizarrerie spécifique que je demande ici se produit sur les deux systèmes.

Si vous lisez Gestion des ressources sous Linux avec des groupes de contrôle, cela donne un exemple montrant comment reproduire le problème. Voici la version d'Ubuntu (exécutez-la en tant que 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

Je m'attendais à ce que le processus "haut" se voit allouer plus de temps que le processus "bas"; ce qui se passe réellement avec ce cas de test ressemble toujours plus à ceci:

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

Où les temps sont presque égaux. Voici ma question: pourquoi cela se produit-il?

Dans la présentation, ce problème est résolu en épinglant chaque processus au même processeur; lignes supplémentaires pour tester que:

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

Le résultat est alors ce que je m'attendais à voir tout le temps: le processus "haut" obtenant un pourcentage beaucoup plus élevé du 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

Expliquer pourquoi cela fonctionne serait une étape utile pour comprendre pourquoi la précédente ne le fait pas aussi.

J'ai obtenu une première explication sur ce cas de test de Stefan Seyfried, qui a écrit le papier dont cet exemple a été tiré. Le problème ici est que les parties d'ordonnanceur CPU de cgroups visent toujours à occuper n'importe quel CPU disponible; il n'impose jamais de limite stricte si tout va convenir à la fois.

Dans le cas où deux processus (haut et bas ici) s'exécutent sur> = 2 cœurs, cela va simplement rester élevé sur un cœur et faible sur l'autre. Les deux s'exécuteront alors tout le temps, à une utilisation proche de 100%, car ils peuvent le faire sans atteindre la situation où le planificateur ne leur donne pas assez de temps sur le processeur. La planification cpu.share ne se produit qu'en cas de pénurie.

Dans le deuxième cas, les deux processus sont épinglés sur le même processeur. Ensuite, la logique de partage du processeur doit faire quelque chose d'utile avec les nombres relatifs de cpu.shares pour les équilibrer, et il le fait comme espéré.

Il est peu probable que des limites strictes sur l'utilisation du CPU apparaissent avant que le patch CFS Bandwidth Control ne soit atteint. À ce stade, il peut être possible d'obtenir quelque chose de plus semblable à ce que j'espérais.