isolcpus
: 14 sty 2020, 20:26
Skrócony opis jest tutaj : https://www.linuxtopia.org/online_books ... /re46.html.
Trzeba zacząć od tego, jak działa wielozadaniowy system operacyjny.
Tak w skrócie, co określony czas jest generowane specjalne przerwanie, które usypia bieżąco wykonywany proces a budzi kolejny umieszczony w kolejce. I tak w kółko. Ponieważ dzieje się to bardzo często a człowiek tak szybkich procesów nie jest w stanie zaobserwować, to wydaje się nam, że kilka procesów działa równocześnie.
Zastosowanie procesorów wielordzeniowych niczego nie uporządkowało, a wręcz przeciwnie, zagmatwało proces i to bardzo.
Uruchamiając monitor systemu na średnio obciążonym komputerze, możemy zauważyć że proces zużywający najwięcej zasobów skacze sobie po kolejnych rdzeniach ...
Jeśli procesor ma dwuwątkowość na fizycznym rdzeniu, to sprawy się jeszcze bardziej komplikują.
Co to oznacza w praktyce ?
Otóż zdarzyć się może, że scheduler systemu operacyjnego przerwie proces na którego wykonaniu nam zależy i na przykład zamiast czytać enkoder zacznie sprawdzać czy przypadkiem nie podłączyłeś czegoś pod USB, albo nie chcesz czegoś wydrukować, albo zacznie Ci upgradować system bo wydano nową wersję firefoksa albo innego libreoffice ...
Nie wszystkie procesy działające w tle da się wyłączyć, choćby dlatego że czasem chcemy z nich skorzystać...
Tutaj z pomocą przychodzi isolcpus, który wyłącza z schedulera systemu operacyjnego określone rdzenie procesora.
Przyjęto, że zadania czasu rzeczywistego są przydzielane rdzeniowi o najwyższym numerze (liczone od zera). Przy rdzeniach jednowątkowych wyłączamy jeden rdzeń, a przy rdzeniach HT musimy wyłączyć też jeden rdzeń fizyczny, ale daje to dwa rdzenie logiczne.
Przykładowo Intel Atom D525 ma dwa rdzenie fizyczne, ale może mieć dwa lub cztery wątki logiczne. W zależności od tego czy w BIOS włączymy wielowątkowość czy nie, trzeba ustawić isolcpus=1 albo isolcpus=2,3 W pierwszym wypadku pozostawiamy systemowi operacyjnemu rdzeń fizyczny 0, w drugim rdzenie logiczne 0 i 1, co w sumie wychodzi na to samo, ale musi być inaczej określone.
Należy zauważyć, że stosując isolcpus spowalniamy system operacyjny kosztem przyśpieszenia wątków czasu rzeczywistego. Czy w konkretnym przypadku będzie to miało sens trzeba ocenić indywidualnie.
Uruchomienie isolcpus odbywa się przez podanie tego parametru w wierszu polecenia GRUB lub innego menadżera rozruchu.
Można to zrobić na stałe, lub jednorazowo. Jednorazowo robi się to zatrzymując bootowanie odpowiednim klawiszem i otwierając wiersz polecenia do edycji. Dokładny opis można znaleźć w internecie.
Na stałe można to zrobić edytując odpowiednie pliki konfiguracyjne, na przykład /etc/default/grub dopisując polecenie do GRUB_CMDLINE_LINUX_DEFAULT="" albo GRUB_CMDLINE_LINUX="" i uruchamiając potem update-grub.
Niestety nie jest to dobre rozwiązanie, bo pierwsza linia dotyczy tylko jednej pozycji "default", a to wcale nie musi być ten kernel co byśmy chcieli, natomiast druga linia dotyczy wszystkich kerneli w systemie, co też może dać wynik którego wcale nie oczekujemy.
W ostateczności można wyedytować plik /boot/grub/grub.cfg , co też nie jest dobrym pomysłem, bo to plik tworzony automatycznie i może zostać nadpisany przez jakiś proces.
Odczytać linię poleceń z którą był uruchomiony bieżący kernel można wydając polecenie cat /proc/cmdline
I to by było na tyle.
Tutaj przykład w praktyce.
Procesor Ryzen5 3400G, cztery rdzenie fizyczne, osiem wątków logicznych, kernel uruchomiony z isolcpus=6,7
Procesor zawalony robotą przez wielowątkową kompilację kernela, a wyłączone rdzenie leniuchują.
W tym przypadku to był błąd, bo do kompilacji lepiej by było wykorzystać wszystkie wątki, no ale ja też się czasem mylę, za to była okazja żeby zrzut ekranu zrobić ...
Trzeba zacząć od tego, jak działa wielozadaniowy system operacyjny.
Tak w skrócie, co określony czas jest generowane specjalne przerwanie, które usypia bieżąco wykonywany proces a budzi kolejny umieszczony w kolejce. I tak w kółko. Ponieważ dzieje się to bardzo często a człowiek tak szybkich procesów nie jest w stanie zaobserwować, to wydaje się nam, że kilka procesów działa równocześnie.
Zastosowanie procesorów wielordzeniowych niczego nie uporządkowało, a wręcz przeciwnie, zagmatwało proces i to bardzo.
Uruchamiając monitor systemu na średnio obciążonym komputerze, możemy zauważyć że proces zużywający najwięcej zasobów skacze sobie po kolejnych rdzeniach ...
Jeśli procesor ma dwuwątkowość na fizycznym rdzeniu, to sprawy się jeszcze bardziej komplikują.
Co to oznacza w praktyce ?
Otóż zdarzyć się może, że scheduler systemu operacyjnego przerwie proces na którego wykonaniu nam zależy i na przykład zamiast czytać enkoder zacznie sprawdzać czy przypadkiem nie podłączyłeś czegoś pod USB, albo nie chcesz czegoś wydrukować, albo zacznie Ci upgradować system bo wydano nową wersję firefoksa albo innego libreoffice ...
Nie wszystkie procesy działające w tle da się wyłączyć, choćby dlatego że czasem chcemy z nich skorzystać...
Tutaj z pomocą przychodzi isolcpus, który wyłącza z schedulera systemu operacyjnego określone rdzenie procesora.
Przyjęto, że zadania czasu rzeczywistego są przydzielane rdzeniowi o najwyższym numerze (liczone od zera). Przy rdzeniach jednowątkowych wyłączamy jeden rdzeń, a przy rdzeniach HT musimy wyłączyć też jeden rdzeń fizyczny, ale daje to dwa rdzenie logiczne.
Przykładowo Intel Atom D525 ma dwa rdzenie fizyczne, ale może mieć dwa lub cztery wątki logiczne. W zależności od tego czy w BIOS włączymy wielowątkowość czy nie, trzeba ustawić isolcpus=1 albo isolcpus=2,3 W pierwszym wypadku pozostawiamy systemowi operacyjnemu rdzeń fizyczny 0, w drugim rdzenie logiczne 0 i 1, co w sumie wychodzi na to samo, ale musi być inaczej określone.
Należy zauważyć, że stosując isolcpus spowalniamy system operacyjny kosztem przyśpieszenia wątków czasu rzeczywistego. Czy w konkretnym przypadku będzie to miało sens trzeba ocenić indywidualnie.
Uruchomienie isolcpus odbywa się przez podanie tego parametru w wierszu polecenia GRUB lub innego menadżera rozruchu.
Można to zrobić na stałe, lub jednorazowo. Jednorazowo robi się to zatrzymując bootowanie odpowiednim klawiszem i otwierając wiersz polecenia do edycji. Dokładny opis można znaleźć w internecie.
Na stałe można to zrobić edytując odpowiednie pliki konfiguracyjne, na przykład /etc/default/grub dopisując polecenie do GRUB_CMDLINE_LINUX_DEFAULT="" albo GRUB_CMDLINE_LINUX="" i uruchamiając potem update-grub.
Niestety nie jest to dobre rozwiązanie, bo pierwsza linia dotyczy tylko jednej pozycji "default", a to wcale nie musi być ten kernel co byśmy chcieli, natomiast druga linia dotyczy wszystkich kerneli w systemie, co też może dać wynik którego wcale nie oczekujemy.
W ostateczności można wyedytować plik /boot/grub/grub.cfg , co też nie jest dobrym pomysłem, bo to plik tworzony automatycznie i może zostać nadpisany przez jakiś proces.
Odczytać linię poleceń z którą był uruchomiony bieżący kernel można wydając polecenie cat /proc/cmdline
I to by było na tyle.
Tutaj przykład w praktyce.
Procesor Ryzen5 3400G, cztery rdzenie fizyczne, osiem wątków logicznych, kernel uruchomiony z isolcpus=6,7
Procesor zawalony robotą przez wielowątkową kompilację kernela, a wyłączone rdzenie leniuchują.
W tym przypadku to był błąd, bo do kompilacji lepiej by było wykorzystać wszystkie wątki, no ale ja też się czasem mylę, za to była okazja żeby zrzut ekranu zrobić ...