Zestaw zadań nie działa na wielu rdzeniach w isolcpus


13

Przedmowę używam Debian Wheezy z jądrem 3.2 na chipsecie AMD64. Moja maszyna ma dwa rdzenie Xeon E5-2690. Ustawiam parametry rozruchowe tak, aby wszystkie rdzenie na jednym procesorze były dedykowane do jednego procesu. Aby to zrobić, ustawiłem isolcpus = 8,9,10,11,12,13,14,15 w grub.

Jak na razie dobrze. Powiedzmy teraz, że chcę użyć izolowanych procesorów dla danego polecenia, aby być prostym, po prostu użyję prostej nieskończonej pętli:

$ taskset -c 8-15 bash -c 'podczas gdy prawda; do echo hello> / dev / null; gotowy' &

Jak dotąd tak dobrze, top pokazuje, że rdzeń 8 obraca się do prawie 100% wykorzystania. Powiedzmy teraz, że ponownie uruchamiam to polecenie:

$ taskset -c 8-15 bash -c 'podczas gdy prawda; do echo hello> / dev / null; gotowy' &

Teraz u góry widać, że rdzenie 9-15 pozostają bezczynne, a dwa procesy współużytkują rdzeń 8. Jeśli zamiast tego zrobię to:

$ taskset -c 8 bash -c 'podczas gdy prawda; do echo hello> / dev / null; gotowy' &

$ taskset -c 9 bash -c 'podczas gdy prawda; do echo hello> / dev / null; gotowy' &

Rdzenie 8 i 9 mają 100% wykorzystania, tak jak powinny. Odnosi się to tylko do isolcpus, ponieważ ten sam zestaw zadań z rdzeniami 1-7 prawidłowo rozkłada procesy na odpowiednie rdzenie. Ponadto „zestaw zadań -p” pokazuje, że maska ​​powinowactwa dla procesów 8-15 jest ustawiona poprawnie. Wygląda na to, że program planujący jądro odmawia użycia czegokolwiek poza najniższym rdzeniem określonym w masce powinowactwa isolcpus.

Teraz normalnie nie byłoby to wielkim problemem z moimi powyższymi przykładami, wystarczy określić poszczególne rdzenie dla każdego procesu. Chcę jednak uruchomić wysoce wielowątkową aplikację na dedykowanym procesorze. Chcę określić zestaw podstawowy i automatycznie korzystać z puli wątków, bez konieczności indywidualnego resetowania koligacji procesora dla każdego spawanego wątku.

Czy ktoś ma pomysł, jak nakłonić program planujący, aby dał mi więcej niż jeden rdzeń z zestawu isolcpu?


czy możesz spróbować użyć programu wielowątkowego? bash nie jest wielowątkowy
c4f4t0r

1
Tak, pierwotnie to mnie zainteresowało (mój program wielowątkowy nie używał więcej niż jednego rdzenia). Prosty skrypt Pythona, który tworzy wiele wątków, nie wykorzystuje więcej niż jednego rdzenia podczas uruchamiania na zestawie izolatora. (Podczas pracy na nieizolowanych rdzeniach wykorzystuje wszystkie dostępne 8 rdzeni).
user79126

przeczytaj ten linuxtopia.org/online_books/linux_kernel/kernel_configuration/... , to wyklucza cpus z harmonogramu jądra, ale po wykluczeniu cpus chcesz uruchomić proces na wykluczonym cpus?
c4f4t0r

1
Jądro nie planuje wątku ani procesu w isolcpu, chyba że maska ​​koligacji procesora wskazuje, że należy go użyć. W przeciwnym razie isolcpus byłby taki sam jak wyłączenie rdzenia, gdy celem jest zarezerwowanie rdzenia z powodu określonego przez użytkownika i upewnienie się, że żaden niepożądany proces go nie używa. Zestaw zadań ustawia maskę koligacji, aby używała wszystkich rdzeni w zakresie 8-15 (który jest ustawiany poprawnie po sprawdzeniu w / proc), więc jądro powinno planować proces na wolnych rdzeniach.
user79126

Odpowiedzi:


10

Po dniu frustracji ustaliłem rozwiązanie. To zachowanie wydaje się być artefaktem domyślnego algorytmu harmonogramu jądra (SCHED_OTHER dla tej dystrybucji / jądra). Zmiana procesu na inny algorytm eliminuje problem, isolcpus są odpowiednio wykorzystywane we wszystkich procesach / wątkach.

Skończyło się na SCHED_RR, ale przetestowałem również SCHED_FIFO i SCHED_IDLE, które wydają się działać. Proces można uruchomić za pomocą alternatywnego algorytmu za pomocą narzędzia chrt:

$ sudo chrt -r 1 [polecenie]

(Jeśli chcesz uruchomić jako użytkownik inny niż root, możesz użyć narzędzia setcap, aby włączyć CAP_SYS_NICE w pliku binarnym związanym z poleceniem)


1
Mimo że ustawianie powinowactwa do rdzeni 0,1, moja aplikacja Java używała tylko pierwszego rdzenia. „sudo chrt -r 1 [polecenie]” rozwiązało również mój problem.
Barry NL
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.