Der Unterschied ist, dass PR ist momentan eine echte Priorität eines Prozesses innerhalb des Kernels und NI ist nur ein Hinweis für den Kernel, welche Priorität der Prozess haben sollte.
In den meisten Fällen PR Der Wert kann nach folgender Formel berechnet werden:PR =20 + NI . Somit hat der Prozess mit Nettigkeit 3 die Priorität 23 (20 + 3) und der Prozess mit Nettigkeit -7 hat die Priorität 13 (20 - 7). Sie können die erste überprüfen, indem Sie den Befehl nice -n 3 top ausführen . Es wird diese Oberseite anzeigen Prozess hat NI 3 und PR 23 . Aber zum Ausführen von nice -n -7 top In den meisten Linux-Systemen müssen Sie Root-Rechte haben, da eigentlich die niedrigere PR Wert ist die höhere tatsächliche Priorität. So der Ablauf mit PR 13 hat eine höhere Priorität als Prozesse mit der Standardpriorität PR 20 . Deshalb müssen Sie root sein. Aber der für Nicht-Root-Prozesse zulässige Mindestwert für die Nettigkeit kann in /etc/security/limits.conf konfiguriert werden .
Theoretisch kann der Kernel PR ändern Wert (aber nicht NI ) von selbst. Beispielsweise kann es die Priorität eines Prozesses verringern, wenn er zu viel CPU verbraucht, oder es kann die Priorität eines Prozesses erhöhen, wenn dieser Prozess wegen anderer Prozesse mit höherer Priorität lange Zeit nicht ausgeführt werden konnte. In diesen Fällen wird die PR Wert wird durch Kernel und NI geändert bleibt gleich, daher die Formel "PR =20 + NI" wird nicht stimmen. Also die NI Der Wert kann als Hinweis für den Kernel interpretiert werden, welche Priorität der Prozess haben sollte, aber der Kernel kann die echte Priorität wählen (PR Wert) je nach Situation alleine. Aber normalerweise die Formel "PR =20 + NI" ist richtig.
Genaue Regeln, wie der Kernel die Priorität ändert, sind nicht klar. Priorität festlegen (die Funktion, die den netten Wert ändert) Handbuch sagt:
Die Auswirkung der Änderung des Nice-Werts kann je nach dem aktiven Prozessplanungsalgorithmus variieren.
Das Pthread-Handbuch sagt Folgendes:
Die dynamische Priorität basiert auf dem Nice-Wert (gesetzt durch nice(2), setpriority(2) oder sched_setattr(2)) und wird jedes Mal erhöht, wenn der Thread laufbereit ist, aber vom Scheduler verweigert wird /P>
Es scheint, dass PR Wert entspricht dynamischer Priorität.
Der Bereich des NI Wert ist -20..19 . Daher die PR value kann die Werte ab 0 annehmen (20 - 20) bis 39 (20 + 19). Aber es ist nur für die Prozesse mit Standardplanungsrichtlinie (SHED_OTHER ). Es kann auch Prozesse mit sogenannter "Echtzeit" geben Planungsrichtlinien. Diese Richtlinien sind SCHED_RR und SCHED_FIFO . Solche Prozesse haben einen PR Wert kleiner als 0. Sie können dies überprüfen, indem Sie chrt -r 1 top ausführen Befehl (muss root sein). Die Oberseite Prozess wird PR -2 haben . Sie können sogar chrt -r 90 top ausführen in diesem Fall oben Prozess wird PR -91 haben .
Es scheint das für SCHED_RR verarbeitet die PR Der Wert kann nach folgender Formel berechnet werden:
PR =- 1 - sched_rr_priority .
Also ein SCHED_RR Prozess hat mindestens PR -1 was bedeutet, dass alle SCHED_RR Prozess hat eine höhere Priorität als alle SCHED_OTHER . Dies entspricht dem pthread-Handbuch:
SCHED_FIFO kann nur mit statischen Prioritäten größer als 0 verwendet werden, was bedeutet, dass ein SCHED_FIFO-Thread, wenn er lauffähig wird, immer sofort jeden derzeit laufenden SCHED_OTHER-, SCHED_BATCH- oder SCHED_IDLE-Thread verdrängt.
SCHED_RR ist eine einfache Erweiterung von SCHED_FIFO. Alles, was oben für SCHED_FIFO beschrieben wurde, gilt auch für SCHED_RR,
Die Priorität von Echtzeitprozessen wird als statische Priorität bezeichnet, die vom Kernel nicht geändert werden kann. So positive PR Werte können als dynamische Priorität für Nicht-Echtzeit behandelt werden (SCHED_OTHER , SCHED_BATCH )-Prozesse und negative PR Wert als statische Priorität für Echtzeitprozesse (SCHED_RR , SCHED_FIFO ).
Ich habe auch versucht, nice -n 10 chrt -r 50 top auszuführen (und chrt -r 50 nice -n 10 top ). Das NI Wert war 10, aber der PR war immer noch -51 . Es scheint also, dass NI Wert wirkt sich nicht auf die Priorität von SCHED_RR aus Prozesse. Dies entspricht setpriority Handbuch:
Alle Prozesse oder Threads, die SCHED_FIFO oder SCHED_RR verwenden, sollen von einem Aufruf von setpriority() nicht betroffen sein. Dies wird nicht als Fehler gewertet. Die Priorität eines Prozesses, der anschließend zu SCHED_OTHER zurückkehrt, muss durch einen solchen setpriority()-Aufruf nicht beeinflusst werden.
Eine lustige Anmerkung. Wenn Sie chrt -r 99 top ausführen , sehen Sie RT Wert anstelle einer Zahl in PR Spalte.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28489 root RT 0 2852 1200 896 R 0 0.1 0:00.01 top
Ich glaube nicht, dass das bedeutet, dass der Prozess jetzt etwas Besonderes ist. Ich denke, das bedeutet, dass top geben Sie einfach nicht -100 aus weil zum Drucken 4 Zeichen benötigt würden.
Sie können auch htop verwenden statt oben in allen Beispielen, die bequemer sein können. ps -l kann auch verwendet werden, aber der Basispunkt, der Echtzeit- und Nicht-Echtzeit-Prioritäten trennt, ist nicht 0, sondern 60, also nice -n -20 ps -l wird gedruckt
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 4 R 0 28983 28804 0 60 -20 - 1176 - pts/6 00:00:00 ps
Der nette Wert ist ein "globaler" Mechanismus, während die Priorität für den Aufgabenwechsler gerade jetzt relevant ist .