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.
źródło
Odpowiedzi:
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.
źródło