Utilizzo di cgroup Linux per bilanciare le prestazioni della CPU

Ho due sistemi Linux dual-core installati usando cgroup Linux con kernel relativamente recenti; uno esegue Debian Squeeze, l'altro Ubuntu 11.04 Natty Narwhal. Ho ottenuto un bilanciamento del carico della CPU con i cgroups che funzionano un po 'meglio sul sistema Debian nonostante il suo kernel più vecchio. Ma non è giusto per tutto, e la stranezza specifica che sto chiedendo qui accade su entrambi i sistemi.

Se leggi Gestione risorse in Linux con gruppi di controllo, viene fornito un esempio che mostra come riprodurre il problema. Ecco la versione di Ubuntu (eseguila come 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

Mi aspettavo che il processo "alto" fosse assegnato più tempo di quello "basso"; ciò che effettivamente accade con questo test è sempre più simile a questo:

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

Dove i tempi sono quasi uguali. Ecco la mia domanda: perché succede?

Nella presentazione, questo problema viene mostrato risolvendo ogni processo sulla stessa CPU; righe aggiuntive per testare che:

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

Il risultato quindi è quello che mi aspettavo di vedere tutto il tempo: il processo "alto" otteneva una percentuale molto più alta della 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

Spiegare perché questo funziona sarebbe un utile passo per capire perché non funziona anche quello precedente.

Ho ricevuto una prima spiegazione su questo caso di test da Stefan Seyfried, che ha scritto l'articolo da cui è stato tratto questo esempio. Il problema qui è che le parti dello schedulatore CPU dei cgroups mirano sempre a tenere occupata qualsiasi CPU disponibile; non imporrà mai un limite rigido se tutto si adatterà immediatamente.

Nel caso in cui due processi (alto e basso qui) sono in esecuzione su> = 2 core, manterrà alto su un core e basso sull'altro. Entrambi funzioneranno quindi continuamente, con un utilizzo prossimo al 100%, perché possono farlo senza colpire la situazione in cui lo scheduler non dà loro abbastanza tempo sulla CPU. La pianificazione di cpu.share avviene solo in caso di carenza.

Nel secondo caso, entrambi i processi sono bloccati sulla stessa CPU. Quindi la logica di condivisione della CPU deve fare qualcosa di utile con i relativi numeri cpu.shares per bilanciarli, e lo fa come sperato.

È probabile che i limiti rigidi sull'utilizzo della CPU non vengano visualizzati fino a quando non viene colpito il patch CFS Bandwidth Control . A quel punto potrebbe essere possibile ottenere qualcosa di più simile a quello che speravo.