Korzystanie z grup Linux w celu zrównoważenia wydajności procesora

Mam dwa dwurdzeniowe systemy Linux zainstalowane przy użyciu grup Linux z względnie nowymi jądrami; na jednym działa Debian Squeeze, na drugim Ubuntu 11.04 Natty Narwhal. Zrównoważyłem obciążenie procesora, dzięki czemu grupy cG pracują nieco lepiej w systemie Debian pomimo jego starszego jądra. Ale to nie jest odpowiednie na wszystko, a konkretna dziwność, o którą tu pytam, występuje w obu systemach.

Jeśli czytasz Zarządzanie zasobami w Linuksie z Grupami kontrolnymi , daje to przykład pokazujący, jak odtworzyć problem. Oto wersja Ubuntu (uruchom jako 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

Spodziewałem się, że procesowi „wysokiemu” poświęci się więcej czasu niż procesowi „niskiemu”; to, co faktycznie dzieje się z tym przypadkiem testowym, jest zawsze bardziej takie:

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

Gdzie czasy są prawie równe. Oto moje pytanie: dlaczego tak się dzieje?

W prezentacji problem ten zniknął, przypinając każdy proces do tego samego procesora; dodatkowe linie do sprawdzenia, czy:

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

Rezultat jest tym, czego spodziewałem się cały czas: proces „wysoki” uzyskuje znacznie wyższy procent procesora:

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

Wyjaśnienie, dlaczego to działa, byłoby przydatnym krokiem w kierunku ustalenia, dlaczego wcześniejszy też nie.

Pierwsze wyjaśnienie dotyczące tego przypadku testowego otrzymałem od Stefana Seyfrieda, który napisał artykuł, z którego wzięto ten przykład. Problem polega na tym, że części cgroups programu planującego procesory zawsze mają na celu utrzymanie zajętości dowolnego dostępnego procesora; nigdy nie wymusza twardego limitu, jeśli wszystko będzie pasować od razu.

W przypadku, gdy dwa procesy (tutaj wysoki i niski) działają na rdzeniach> = 2, po prostu utrzyma wysoki poziom na jednym rdzeniu i niski na drugim. Oba będą wtedy działać przez cały czas, przy prawie 100% użyciu, ponieważ mogą to zrobić bez narażania się na sytuację, w której program planujący nie zapewnia im wystarczającej ilości czasu na procesor. Planowanie cpu.share dzieje się tylko wtedy, gdy brakuje.

W drugim przypadku oba procesy są przypięte do tego samego procesora. Następnie logika współdzielenia procesora musi zrobić coś użytecznego z względnymi liczbami procesora. Dzieli się, aby je zrównoważyć, i robi to zgodnie z oczekiwaniami.

Twarde ograniczenia użycia procesora prawdopodobnie nie pojawią się, dopóki nie pojawi się łatka CFS Bandwidth Control . W tym momencie może być możliwe uzyskanie czegoś bardziej podobnego do tego, na co liczyłem.