Jak powinowactwo procesora współdziała z cgroups w systemie Linux?

Próbuję uruchomić wielowątkowe testy porównawcze na zestawie izolowanych procesorów. Krótko mówiąc, początkowo próbowałem z isolcpusi taskset, ale natrafiłem na problemy . Teraz gram z cgroups / cset.

Myślę, że „prosty” cset shieldprzypadek użycia powinien dobrze działać. Mam 4 rdzenie, więc chciałbym użyć rdzeni 1-3 do testów porównawczych (skonfigurowałem również te rdzenie, aby były w trybie adaptacyjnych tików), a następnie rdzeń 0 można wykorzystać do wszystkiego innego.

Zgodnie z tutorialem tutaj powinno być tak proste, jak:

$ sudo cset shield -c 1-3
cset: --> shielding modified with:
cset: "system" cpuset of CPUSPEC(0) with 105 tasks running
cset: "user" cpuset of CPUSPEC(1-3) with 0 tasks running

Mamy teraz „osłonę”, która jest izolowana (zestaw użytkowników), a rdzeń 0 dotyczy wszystkiego innego (zestawu systemowego).

Dobra, na razie wygląda dobrze. Teraz spójrzmy na htop. Wszystkie procesy powinny zostać migrowane do CPU 0:

Co? Niektóre procesy są wyświetlane jako wykonywane na ekranowanych rdzeniach. Aby wykluczyć przypadek, w którym htop ma błąd, próbowałem również użyć tasksetmaski inspekcyjnej procesu pokazanego jako tarcza.

Może te zadania były nieporuszalne? Podciągnijmy dowolny proces pokazany jako działający na CPU3 (który powinien znajdować się w osłonie) htopi zobaczmy, czy pojawia się on w grupie systemowej zgodnie z cset:

$ cset shield -u -v | grep 864
   root       864     1 Soth [gmain]
   vext01    2412  2274 Soth grep 864 

Tak, to działa w grupie systemowej zgodnie z cset. Więc htopi csetnie zgadzam się.

Co się tu dzieje? Komu ufam: koligacje procesorów ( htop/ taskset) czy cset?

Podejrzewam, że nie powinniście używać csetrazem i powinowactwa razem. Być może tarcza działa dobrze i powinienem zignorować maski koligacji i htopdane wyjściowe. Tak czy inaczej uważam to za mylące. Czy ktoś może rzucić trochę światła?

Z dokumentacji cpusets :

Wywołania harmonogramu_setaffinity są filtrowane tylko do procesorów dozwolonych w zestawie zadań tego zadania.

Oznacza to, że maski koligacji procesora są przecinane z cpus w grupie cgroup, której proces jest członkiem.

Np. Jeśli maska ​​powinowactwa procesu zawiera rdzenie {0, 1, 3}, a proces działa w systemie cgroup, który jest ograniczony do rdzeni {1, 2}, wówczas proces byłby zmuszony do uruchomienia na rdzeniu 1.

Jestem w 99% pewien, że dane htopwyjściowe są „błędne”, ponieważ procesy nie obudziły się od czasu utworzenia grup cg, a wyświetlacz pokazuje ostatni rdzeń, na którym uruchomiono proces.

Jeśli zacznę vim przed zrobieniem mojej tarczy, vim rozwinie się dwa razy (z jakiegoś powodu), a najgłębsze dziecko działa na rdzeniu 2. Jeśli następnie stworzę tarczę, to uśpij vim (ctrl + z) i obudz ją, oba procesy mają przeniesiono do rdzenia 0. Myślę, że to potwierdza hipotezę, że htoppokazuje nieaktualne informacje.

Możesz także sprawdzić /proc/<pid>/statusi przejrzeć cpus_allowed_*pola.

Np. Mam tutaj console-kit-daemonproces (pid 857) pokazujący w htopie jako działający na rdzeniu 3, ale w /proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

Myślę, że to mówi, że maska ​​powinowactwa to 0x1, co pozwala na działanie tylko na rdzeniu 1 z powodu cgroups: tj. Przecinają się ({0,1,2,3}, {0}) = {0}.

Jeśli mogę, zostawię pytanie otwarte, aby sprawdzić, czy pojawi się jakaś lepsza odpowiedź.

Dzięki @davmac za pomoc w tym (na irc).