Kurze Antwort
99 wird der Gewinner für Echtzeitpriorität sein.
PR ist die Prioritätsstufe (Bereich -100 bis 39). Je niedriger der PR, desto höher die Priorität des Prozesses.
PR wird wie folgt berechnet:
- für normale Prozesse:PR =20 + NI (NI ist nett und reicht von -20 bis 19)
- für Echtzeitprozesse:PR =- 1 - real_time_priority(real_time_priority reicht von 1 bis 99)
Lange Antwort
Es gibt 2 Arten von Prozessen, den normalen Einsen und die Echtzeit Für die normalen (und nur für diese) wird nice wie folgt angewendet:
Schön
Die „Niceness“-Skala reicht von -20 bis 19, wobei -20 die höchste Priorität und 19 die niedrigste Priorität ist. Die Prioritätsstufe wird wie folgt berechnet:
PR =20 + NI
Wobei NI die Nice-Ebene und PR die Prioritätsebene ist. Wie wir also sehen können, wird die -20 tatsächlich auf 0 abgebildet, während die 19 auf 39 abgebildet wird.
Standardmäßig ist ein Programm-Nice-Wert 0 Bit. Es ist für einen Root-Benutzer möglich, Programme mit einem bestimmten Nice-Wert zu öffnen, indem er den folgenden Befehl verwendet:
nice -n <nice_value> ./myProgram
Echtzeit
Wir könnten sogar noch weiter gehen. Die nette Priorität wird tatsächlich für Benutzerprogramme verwendet. Während die UNIX/LINUX-Gesamtpriorität einen Bereich von 140 Werten hat, ermöglicht nice value dem Prozess, den letzten Teil des Bereichs (von 100 bis 139) abzubilden. Diese Gleichung lässt die Werte von 0 bis 99 unerreichbar, was einem negativen PR-Level entspricht (von -100 bis -1). Um auf diese Werte zugreifen zu können, sollte der Prozess als "Echtzeit" angegeben werden.
Es gibt 5 Planungsrichtlinien in einer LINUX-Umgebung, die mit dem folgenden Befehl angezeigt werden können:
chrt -m
Dadurch wird die folgende Liste angezeigt:
1. SCHED_OTHER the standard round-robin time-sharing policy
2. SCHED_BATCH for "batch" style execution of processes
3. SCHED_IDLE for running very low priority background jobs.
4. SCHED_FIFO a first-in, first-out policy
5. SCHED_RR a round-robin policy
Die Scheduling-Prozesse könnten in 2 Gruppen unterteilt werden, die normalen Scheduling-Richtlinien (1 bis 3) und die Echtzeit-Scheduling-Richtlinien (4 und 5). Die Echtzeit-Prozesse haben immer Vorrang vor normalen Prozessen. Ein Echtzeitprozess könnte mit dem folgenden Befehl aufgerufen werden (das Beispiel zeigt, wie eine SCHED_RR-Richtlinie deklariert wird):
chrt --rr <priority between 1-99> ./myProgram
Um den PR-Wert für einen Echtzeitprozess zu erhalten, wird die folgende Gleichung angewendet:
PR =-1 - rt_prior
Wobei rt_prior der Priorität zwischen 1 und 99 entspricht. Aus diesem Grund wird der mit der Nummer 99 aufgerufene Prozess die höhere Priorität gegenüber anderen Prozessen haben.
Es ist wichtig zu beachten, dass für Echtzeitprozesse der Nice-Wert nicht verwendet wird.
Um die aktuelle „Nettigkeit“ und den PR-Wert eines Prozesses zu sehen, kann der folgende Befehl ausgeführt werden:
top
Was die folgende Ausgabe zeigt:
In der Abbildung werden die PR- und NI-Werte angezeigt. Es ist gut, den Prozess mit dem PR-Wert -51 zu beachten, der einem Echtzeitwert entspricht. Es gibt auch einige Prozesse, deren PR-Wert als "rt" angegeben wird. Dieser Wert entspricht tatsächlich einem PR-Wert von -100.
Dieser Kommentar in sched.h ist ziemlich eindeutig:
/*
* Priority of a process goes from 0..MAX_PRIO-1, valid RT
* priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH
* tasks are in the range MAX_RT_PRIO..MAX_PRIO-1. Priority
* values are inverted: lower p->prio value means higher priority.
*
* The MAX_USER_RT_PRIO value allows the actual maximum
* RT priority to be separate from the value exported to
* user-space. This allows kernel threads to set their
* priority to a value higher than any user task. Note:
* MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
*/
Beachten Sie diesen Teil:
Prioritätswerte sind invertiert:p->prio niedriger Wert bedeutet höhere Priorität .
Ich habe ein Experiment durchgeführt, um dies festzunageln, wie folgt:
-
Prozess1:RT-Priorität =40, CPU-Affinität =CPU 0. Dieser Prozess "dreht" sich 10 Sekunden lang, sodass kein Prozess mit niedrigerer Priorität auf CPU 0 ausgeführt werden kann.
-
Prozess2:RT-Priorität =39, CPU-Affinität =CPU 0. Dieser Prozess gibt alle 0,5 Sekunden eine Nachricht an stdout aus und schläft dazwischen. Es druckt die verstrichene Zeit mit jeder Nachricht.
Ich verwende einen 2.6.33-Kernel mit dem PREEMPT_RT-Patch.
Um das Experiment auszuführen, führe ich Prozess2 in einem Fenster (als Root) aus und starte dann Prozess1 (als Root) in einem anderen Fenster. Das Ergebnis ist, dass Prozess1 Prozess2 zu unterbrechen scheint und ihm nicht erlaubt, für volle 10 Sekunden zu laufen.
In einem zweiten Experiment ändere ich die RT-Priorität von Prozess2 auf 41. In diesem Fall ist Prozess2 nicht von Prozess1 vorweggenommen.
Dieses Experiment zeigt, dass ein größer RT-Prioritätswert in sched_setscheduler() hat eine höhere Priorität. Dies scheint dem zu widersprechen, was Michael Foukarakis in sched.h aufgezeigt hat, ist es aber tatsächlich nicht. In sched.c in den Kernelquellen haben wir:
static void
__setscheduler(struct rq *rq, struct task_struct *p, int policy, int prio)
{
BUG_ON(p->se.on_rq);
p->policy = policy;
p->rt_priority = prio;
p->normal_prio = normal_prio(p);
/* we are holding p->pi_lock already */
p->prio = rt_mutex_getprio(p);
if (rt_prio(p->prio))
p->sched_class = &rt_sched_class;
else
p->sched_class = &fair_sched_class;
set_load_weight(p);
}
rt_mutex_getprio(p) macht folgendes:
return task->normal_prio;
Während normal_prio() folgendes macht:
prio = MAX_RT_PRIO-1 - p->rt_priority; /* <===== notice! */
...
return prio;
Mit anderen Worten, wir haben (meine eigene Interpretation):
p->prio = p->normal_prio = MAX_RT_PRIO - 1 - p->rt_priority
Wow! Das ist verwirrend! Zusammenfassend:
-
Bei p->prio verdrängt ein kleinerer Wert einen größeren Wert.
-
Bei p->rt_priority hat ein größerer Wert Vorrang vor einem kleineren Wert. Dies ist die mit
sched_setscheduler()eingestellte Echtzeitpriorität .