Wie ändere ich die Häufigkeit von Linux-Kontextwechseln?

Wie ist es möglich, die Häufigkeit des Kontextwechsels unter Linux (Linaro, Ubuntu, Debian) zu ändern?

Es ist in Ordnung, ein weniger ansprechendes System gegen ein effizienteres auszutauschen.

EDIT1: Ich habe einen Hauptprozess, den ich so schnell wie möglich ausführen möchte (maximale Taktzyklen pro Sekunde), also habe ich darüber nachgedacht, die Häufigkeit des Kontextwechsels zu reduzieren (= die Zeitscheibe zu erhöhen). Die Frage ist, wie es geht und ob es einen signifikanten Effekt gibt. Kann ich die Kosten für den Kontextwechsel berechnen? Kann ich abschätzen, ob ich die Zeitscheibe um zwei verlängere, was mein Leistungsgewinn in% für den Hauptprozess ist, der mich interessiert?

Wenn Ihre Aufgabe der einzige Prozess ist, der Zeit für eine bestimmte CPU anfordert, gibt es keine Kontextwechsel zwischen den Aufgaben :-). Möglicherweise ist die CPU jedoch immer noch unterbrochen, was zu einem Kontextwechsel in den Kernel und zurück führt. Und eine mögliche Ursache ist der Pre-Emission-Timer, der prüft, ob auf dieser CPU eine andere Aufgabe ausgeführt werden muss ...

Linux kann die Erzeugung von Interrupts für den Pre-Emission-Timer auf der CPU vermeiden, wenn es keinen Grund dafür gibt. Sehen CONFIG_NO_HZ_FULL. Um diese Funktion zu nutzen, muss er aktiviert werden , wenn der Kernel gebaut wurde, und es muss mit einer Boot - Option aktiviert werden.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "(Fast) voller tickless Betrieb in 3.10"

Standardmäßig ist keine CPU eine Adaptive-Ticks-CPU. Der Boot-Parameter "nohz_full =" gibt die Adaptive-Ticks-CPUs an. Beispielsweise besagt "nohz_full = 1,6-8", dass die CPUs 1, 6, 7 und 8 CPUs mit adaptiven Ticks sein sollen. Beachten Sie, dass Sie nicht alle CPUs als Adaptive-Tick-CPUs kennzeichnen dürfen [...]

Laut LWN.net werden laut Ingo Molnar bis zu 1% der CPU-Zeit für Adaptive-Ticks-CPUs eingespart. Das Kerneldokument besagt, dass dies sechs verschiedene Kosten hat, und es gibt auch eine Liste von "BEKANNTEN PROBLEMEN".

Dieser Gewinn ist relativ gering, insbesondere im Vergleich zu den potenziellen Durchsatzgewinnen bei der Reduzierung der Häufigkeit von Kontextwechseln zwischen mehreren Tasks, auf die in der folgenden Antwort verwiesen wird: Wie ändere ich die Länge der vom Linux-CPU-Scheduler verwendeten Zeitscheiben?

Kleingedrucktes: Diese Messungen datieren Spectre, Meltdown, KPTI und x86 ASID-Unterstützung voraus :-(. Und ich denke, sie gelten auch für etwas ältere Hardware. Fragen Sie einen Kernel-Experten oder führen Sie Ihre eigenen Messungen durch, wie hoch die Kosten für Kontextwechsel sind Änderungen an Ihrer spezifischen Kernel-Version und Hardware ... PTI sollte größtenteils von ASID gemildert werden, mit Ausnahme von Software, die sehr häufig in den Kernel ruft, wobei das Hauptbeispiel Datenbanken sind .

Molnars Hoffnung im ursprünglichen RFC-Patch war, dass es mit der Zeit "wahrscheinlich von den meisten Linux-Distributionen aktiviert wird". Ich stelle fest, dass Fedora 28 einen mit NO_HZ_FULLUnterstützung erstellten Standardkernel bereitstellt . Debian 9 jedoch nicht.

In jüngerer Zeit entferntnohz_full Linux v4.17 einen verbleibenden 1-Hz-Timer-Tick von den CPUs . Ich stelle mir vor, dass die Auswirkung auf den Durchsatz recht gering ist :-), aber ich habe versucht, den Status der NO_HZ_FULLVorteile zu verfolgen, wenn auf einer CPU mehrere ausführbare Prozesse vorhanden sind.

Wenn wir 0 Hz erreichen, können wir die periodische Tick-Annahme auch aus nr_running> = 2 entfernen, indem wir ausgelastete Tasks im Wesentlichen nur so oft unterbrechen, wie es die sched_latency-Einschränkungen erfordern - je nach nr_running alle 4 bis 40 ms .

Dies ist etwas verwirrend, da die Voreinstellung bereits mit einem separaten, genaueren Tick in Version 2.6.25-rc1, Commit 8f4d37ec073c, "sched: high-res preemption tick" begonnen hat . Gefunden über diesen Kommentar zum gleichen Artikel von LWN.net: https://lwn.net/Articles/549754/ ).