Welche Echtzeitpriorität hat unter Linux die höchste Priorität?

Im Linux-Echtzeitprozessprioritätsbereich 1 bis 99 ist mir unklar, welche Priorität 1 oder 99 die höchste Priorität hat.

In Abschnitt 7.2.2 von "Grundlegendes zum Linux-Kernel" (O'Reilly) heißt es, dass 1 die höchste Priorität hat. Dies ist sinnvoll, wenn man bedenkt, dass normale Prozesse statische Prioritäten von 100 bis 139 haben, wobei 100 die höchste Priorität hat:

"Jeder Echtzeitprozess ist mit einer Echtzeitpriorität verbunden, die zwischen 1 (höchste Priorität) und 99 (niedrigste Priorität) liegt."

Andererseits behauptet die Manpage sched_setscheduler (RHEL 6.1), dass 99 die höchste ist:

"Prozesse, die unter einer der Echtzeitrichtlinien (SCHED_FIFO, SCHED_RR) geplant sind, haben einen Sched_priority-Wert im Bereich von 1 (niedrig) bis 99 (hoch)."

Welches ist die höchste Echtzeitpriorität?

Ich habe ein Experiment durchgeführt, um dies wie folgt festzunageln:

• 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 wird.

• Prozess2: RT-Priorität = 39, CPU-Affinität = CPU 0. Dieser Prozess druckt alle 0,5 Sekunden eine Nachricht an stdout und schläft dazwischen. Mit jeder Nachricht wird die verstrichene Zeit ausgedruckt.

Ich verwende einen 2.6.33-Kernel mit dem PREEMPT_RT-Patch.

Um das Experiment auszuführen, führe ich process2 in einem Fenster (als root) aus und starte dann process1 (als root) in einem anderen Fenster. Das Ergebnis ist, dass Prozess1 Prozess2 anscheinend vorwegnimmt und ihn nicht für volle 10 Sekunden laufen lässt.

In einem zweiten Experiment ändere ich die RT-Priorität von Prozess2 auf 41. In diesem Fall wird Prozess2 von Prozess1 nicht vorgezogen.

Dieses Experiment zeigt, dass ein größerer RT-Prioritätswert in sched_setscheduler () eine höhere Priorität hat. Dies scheint dem zu widersprechen, worauf Michael Foukarakis in sched.h hingewiesen hat, aber tatsächlich nicht. In sched.c in der Kernelquelle 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) führt Folgendes aus:

return task->normal_prio;

Während normal_prio () Folgendes tut:

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

Beeindruckend! Das ist verwirrend! Zusammenfassen:

• Bei p-> prio steht ein kleinerer Wert vor einem größeren Wert.

• Mit p-> rt_priority geht ein größerer Wert einem kleineren Wert voraus. Dies ist die Echtzeitpriorität, die mit sched_setscheduler () festgelegt wurde.

Kurze Antwort

99 wird der Gewinner für die Echtzeitpriorität sein.

PR ist die Prioritätsstufe (Bereich -100 bis 40). Je niedriger die PR, desto höher ist 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 zwei Arten von Prozessen, die normalen und die Echtzeitprozesse. Für die normalen (und nur für diese) wird nice wie folgt angewendet:

nett

Die Skala "Freundlichkeit" reicht von -20 bis 19, während -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 das nette Level und PR das Prioritätslevel ist. Wie wir sehen können, ist die -20 tatsächlich auf 0 abgebildet, während die 19 auf 39 abgebildet ist.

Standardmäßig ist ein Programm-Nizza-Wert 0 Bit. Ein Root-Benutzer kann Programme mit einem angegebenen Nizza-Wert mithilfe des folgenden Befehls zu Mittag essen:

nice -n <nice_value> ./myProgram 

Echtzeit

Wir könnten noch weiter gehen. Die nette Priorität wird eigentlich für Anwenderprogramme verwendet. Während die UNIX / LINUX-Gesamtpriorität einen Bereich von 140 Werten hat, ermöglicht der schöne Wert dem Prozess, den letzten Teil des Bereichs (von 100 bis 139) abzubilden. Diese Gleichung lässt die Werte von 0 bis 99 nicht erreichbar, was einem negativen PR-Wert (von -100 bis -1) entspricht. Um auf diese Werte zugreifen zu können, sollte der Prozess als "Echtzeit" angegeben werden.

In einer LINUX-Umgebung gibt es 5 Planungsrichtlinien, die mit dem folgenden Befehl angezeigt werden können:

chrt -m 

Welches wird die folgende Liste zeigen:

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 Planungsprozesse können in zwei Gruppen unterteilt werden, die normalen Planungsrichtlinien (1 bis 3) und die Echtzeit-Planungsrichtlinien (4 und 5). Die Echtzeitprozesse haben immer Vorrang vor normalen Prozessen. Ein Echtzeitprozess kann mit dem folgenden Befehl aufgerufen werden (Beispiel: Deklarieren einer SCHED_RR-Richtlinie):

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 Prozess, der gegenüber anderen Prozessen die höhere Priorität hat, mit der Nummer 99 aufgerufen.

Es ist wichtig zu beachten, dass für Echtzeitprozesse der nette Wert nicht verwendet wird.

Um die aktuelle "Schönheit" und den PR-Wert eines Prozesses anzuzeigen, kann der folgende Befehl ausgeführt werden:

top

Welches zeigt die folgende Ausgabe:

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 definitiv:

/*
 * 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 werden invertiert: Ein niedrigerer p->prioWert bedeutet eine höhere Priorität .

Verwenden Sie die Funktion sched_get_priority_max, um die höchste Echtzeitpriorität zu bestimmen, die Sie programmgesteuert festlegen können.

Unter Linux 2.6.32 gibt ein Aufruf von sched_get_priority_max (SCHED_FIFO) 99 zurück.

Siehe http://linux.die.net/man/2/sched_get_priority_max

Ihre Annahme, dass normale Prozesse statische Prioritäten von 100 bis 139 haben, ist bestenfalls volatil und im schlimmsten Fall ungültig. Was ich damit meine ist, dass: set_scheduler nur zulässt, dass die sched_priority mit SCHED_OTHER / SCHED_BATCH und SCHED_IDLE (true ab 2.6.16) 0 ist (was einen dynamischen Prioritätsplaner anzeigt).

Programmatisch statische Prioritäten sind 1-99 nur für SCHED_RR und SCHED_FIFO

Jetzt können Sie sehen, dass Prioritäten von 100-139 intern von einem dynamischen Scheduler verwendet werden. Was der Kernel jedoch intern tut, um dynamische Prioritäten zu verwalten (einschließlich des Umkippens der Bedeutung von hoher oder niedriger Priorität, um den Vergleich oder das Sortieren zu erleichtern), sollte undurchsichtig sein in den User-Space.

Denken Sie daran, dass Sie in SCHED_OTHER die Prozesse meistens in dieselbe Prioritätswarteschlange stellen.

Die Idee ist, das Kernel einfacher zu debuggen und doofe Fehler zu vermeiden.

Das Grundprinzip beim Ändern der Bedeutung könnte also sein, dass ein Kernel-Entwickler keine Mathematik wie 139-idx verwenden möchte (nur für den Fall, dass idx> 139 ist) ... es ist besser, mit idx-100 zu rechnen und das Konzept umzukehren von niedrig gegen hoch, weil idx <100 gut verstanden wird.

Ein Nebeneffekt ist auch, dass die Freundlichkeit leichter zu handhaben ist. 100 - 100 <=> nice == 0; 101-100 <=> nice == 1; usw. ist einfacher. Es kollabiert auch gut zu negativen Zahlen (NICHTS, was mit statischen Prioritäten zu tun hat) 99 - 100 <=> nice == -1 ...

1. Die Echtzeitpriorität gilt absolut für die RT-Richtlinien FIFO und RR, die zwischen 0 und 99 variieren.

2. Wir haben die 40 als Zählung der Nicht-Echtzeit-Prozesspriorität für BATCH, ANDERE Richtlinien, die von 0 bis 39 und nicht von 100 bis 139 variiert. Dies können Sie beobachten, indem Sie sich jeden Prozess im System ansehen, der keine Echtzeit ist Prozess. Es wird standardmäßig eine PR von 20 und eine NIceness von 0 tragen. Wenn Sie die Schönheit eines Prozesses verringern (normalerweise niedriger oder negativ, die Zahl geringer als die Schönheit, hungriger der Prozess), beispielsweise von 0 auf -1, werden Sie feststellen, dass die Priorität von 20 auf 19 sinkt. Dies zeigt einfach Wenn Sie einen Prozess hungriger machen oder durch Verringern des Nizza-Werts der PID etwas mehr Aufmerksamkeit erhalten möchten, wird auch die Priorität verringert, wodurch die PRIORITÄTSzahl HÖHER als die PRIORITÄT gesenkt wird.

   Example:
   
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   2079 admin     10 -10  280m  31m 4032 S  9.6  0.0  21183:05 mgmtd
   [[email protected] ~]# renice -n -11 2079
   2079: old priority -10, new priority -11
   [[email protected] ~]# top -b | grep mgmtd
   2079 admin      9 -11  280m  31m 4032 S  0.0  0.0  21183:05 mgmtd
   ^C
   

Ich hoffe, dieses praktische Beispiel klärt die Zweifel und kann helfen, die Wörter an einer falschen Quelle zu korrigieren, falls vorhanden.

Der Linux-Kernel implementiert zwei separate Prioritätsbereiche -

1. Schöner Wert: -20 bis +19; größere schöne Werte entsprechen einer niedrigeren Priorität .

2. Echtzeitpriorität: 0 bis 99; Höhere Echtzeitprioritätswerte entsprechen einer höheren Priorität .