Jak zmienić częstotliwość przełączania kontekstu w systemie Linux?

Jak można zmienić częstotliwość przełączania kontekstu w Linuksie (Linaro, Ubuntu, Debian)?

Nie przeszkadza mi zamiana mniej responsywnego systemu na bardziej wydajny.

EDYCJA 1: Mam główny proces, który chcę uruchomić tak szybko, jak to możliwe (maksymalne cykle zegara na sekundę), więc pomyślałem o zmniejszeniu częstotliwości przełączania kontekstu (= zwiększenie przedziału czasu). Pytanie brzmi, jak to zrobić i czy miałby to znaczący wpływ. Czy mogę obliczyć koszt zmiany kontekstu? Czy mogę oszacować, jeśli zwiększę przedział czasu o dwa, jaki będzie mój wzrost wydajności w% dla głównego procesu, na którym mi zależy?

Jeśli twoje zadanie jest jedynym procesem żądającym czasu na konkretnym procesorze, nie będzie przełączania kontekstu między zadaniami :-). Ale procesor może być nadal przerywany, powodując zmianę kontekstu w jądrze iz powrotem. Jedną z możliwych przyczyn jest licznik czasu wyprzedzającego, sprawdzający, czy na tym procesorze jest inne zadanie ...

Linux może uniknąć generowania przerwań czasomierza wyprzedzającego na jednostce centralnej, gdy nie będzie żadnego powodu, aby to zrobić. Zobaczyć CONFIG_NO_HZ_FULL. Aby użyć tej funkcji, należy ją włączyć podczas budowania jądra i włączyć ją przy użyciu opcji rozruchu.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(Niemal) pełna operacja tykania w 3.10"

Domyślnie żaden procesor nie będzie procesorem dopasowującym. Parametr rozruchowy „nohz_full =” określa procesory adaptacyjne. Na przykład „nohz_full = 1,6-8” mówi, że procesory 1, 6, 7 i 8 mają być procesorami adaptacyjnymi. Uwaga: zabrania się oznaczania wszystkich procesorów jako procesorów z adaptacyjnym tykaniem [...]

LWN.net mówi „według Ingo Molnar zaoszczędzi nawet 1% czasu procesora” na procesory z adaptacyjnym tikiem. Dokument jądra mówi, że wiąże się to z sześcioma różnymi kosztami, a także istnieje lista „ZNANYCH PROBLEMÓW”.

Zysk ten jest stosunkowo niewielki, szczególnie w porównaniu z potencjalnym wzrostem przepustowości wynikającym ze zmniejszenia częstotliwości przełączania kontekstu między wieloma zadaniami, jak wspomniano w odpowiedzi: Jak zmienić długość przedziałów czasowych używanych przez program planujący procesor w systemie Linux?

Mały wydruk: te pomiary są wcześniejsze niż obsługa ASID Spectre, Meltdown, KPTI i x86 :-(. Myślę, że dotyczą one również nieco starszego sprzętu. Zapytaj eksperta od jądra lub przeprowadź własne pomiary, jak koszt przełączników kontekstu ma zmieniono na konkretną wersję jądra i sprzęt ... PTI miał być w dużej mierze złagodzony przez ASID, z wyjątkiem oprogramowania, które bardzo często wywołuje jądro, czego głównym przykładem są bazy danych. Ale nie rozumiem dobrze liczb .

Nadzieja Molnara w oryginalnej łatce RFC była taka, że ​​z czasem „prawdopodobnie zostanie ona włączona przez większość dystrybucji Linuksa”. Zauważam, że Fedora 28 zapewnia domyślne jądro zbudowane z NO_HZ_FULLobsługą. Jednak Debian 9 nie.

Niedawno Linux v4.17 usuwa resztkowenohz_full taktowanie zegara 1 Hz z procesorów . Wyobrażam sobie, że wpływ na przepustowość jest dość niewielki :-), ale starałem się śledzić status NO_HZ_FULLkorzyści, gdy procesor ma wiele uruchomionych procesów -

gdy osiągniemy 0 Hz, możemy [następnie] usunąć założenie okresowego tykania również z nr_running> = 2, w zasadzie przerywając zajęte zadania tylko tak często, jak wymagają tego ograniczenia harmonogramu_latencji - raz na 4-40 ms, w zależności od nr_running .

Jest to nieco mylące, ponieważ uprzedzanie rozpoczęło się już przy użyciu osobnego, bardziej precyzyjnego haczyka z powrotem w v2.6.25-rc1, commit 8f4d37ec073c, „harmonogram: kleszcza z wyprzedzeniem wysokiej rozdzielczości” . Znaleziono za pomocą tego komentarza do tego samego artykułu LWN.net: https://lwn.net/Articles/549754/ ).