Wenn ich in zweiandersRoot-Terminals:
nice -n 19 burnK7 &
Und
nice -n -19 burnK7 &
Dann erhalten beide Prozesse etwa 50 % der verfügbaren CPU-Zeit – nicht erwartet und sicher nicht erwünscht.
Wenn ich imDasselbeRoot-Terminal:
nice -n 19 burnK7 &
nice -n -19 burnK7 &
Der erste Prozess erhält wie erwartet etwa 0 % und der zweite etwa 100 % der verfügbaren CPU-Zeit.
Ist das ein Fehler oder ein Feature?
Ich verwende Arch Linux mit der Kernelversion 3.16 auf einer Single-Core-Maschine, soweit das sinnvoll ist.
Antwort1
Also, nun, im Nachhinein, hier einige Informationen. Das Verhalten, das Sie sehen, ist auf die Autogroup-Funktion zurückzuführen, die in Linux 2.6.38 (im Jahr 2010) hinzugefügt wurde. Hier ist eine bearbeitete Version eines Textes, den ich gleich zumsched(7)Handbuchseitedas erklärt, was Sie sehen.
Der Kernel stellt eine Funktion namens „Autogrouping“ bereit, um die Leistung des interaktiven Desktops bei CPU-intensiven Multiprozess-Workloads zu verbessern, wie etwa beim Erstellen des Linux-Kernels mit einer großen Anzahl paralleler Build-Prozesse (d. h. das make(1) -jFlag).
Eine neue Autogroup wird erstellt, wenn eine neue Sitzung über erstellt wird setsid(2); dies geschieht beispielsweise, wenn ein neues Terminalfenster geöffnet wird. Ein neuer Prozess, der über erstellt wird, fork(2)erbt die Autogroup-Mitgliedschaft seines übergeordneten Prozesses. Somit sind alle Prozesse in einer Sitzung Mitglieder derselben Autogroup.
Wenn die automatische Gruppierung aktiviert ist, werden alle Mitglieder einer automatischen Gruppe in derselben Kernel-Scheduler-Aufgabengruppe platziert. Der Linux-Kernel-Scheduler verwendet einen Algorithmus, der die Verteilung der CPU-Zyklen auf die Aufgabengruppen ausgleicht. Die Vorteile für die interaktive Desktop-Leistung können anhand des folgenden Beispiels beschrieben werden.
Angenommen, es gibt zwei Autogroups, die um dieselbe CPU konkurrieren (nehmen Sie also entweder ein System mit einer CPU an oder die Verwendung von , taskset(1)
um alle Prozesse auf einem SMP-System auf dieselbe CPU zu beschränken). Die erste Gruppe enthält zehn CPU-gebundene Prozesse aus einem Kernel-Build, der mit gestartet wurde make -j10. Die andere enthält einen einzigen CPU-gebundenen Prozess: einen Videoplayer. Die Autogrouping-Funktion hat zur Folge, dass die beiden Gruppen jeweils die Hälfte der CPU-Zyklen erhalten. Das bedeutet, dass der Videoplayer 50 % der CPU-Zyklen erhält statt nur 9 % der Zyklen, was wahrscheinlich zu einer verschlechterten Videowiedergabe führen würde. Auf einem SMP-System ist die Situation komplexer, aber die allgemeine Wirkung ist dieselbe: Der Scheduler verteilt die CPU-Zyklen auf die Taskgruppen, sodass eine Autogroup mit einer großen Zahl CPU-gebundener Prozesse nicht letztendlich CPU-Zyklen auf Kosten anderer Jobs im System beansprucht.
Das gute Preis-Leistungs-Verhältnis und die Gruppenplanung
Beim Planen von Nicht-Echtzeitprozessen (z. B. solchen, die gemäß der Standardrichtlinie geplant werden SCHED_OTHER) verwendet der Planer eine Technik namens „Gruppenplanung“, bei der Threads in „Aufgabengruppen“ geplant werden. Aufgabengruppen werden unter verschiedenen Umständen gebildet, wobei hier die automatische Gruppierung relevant ist.
Wenn die automatische Gruppierung aktiviert ist, bilden alle Threads, die (implizit) in einer automatischen Gruppe platziert werden (d. h. in derselben Sitzung, wie sie von erstellt wurde setsid(2)), eine Aufgabengruppe. Jede neue automatische Gruppe ist somit eine separate Aufgabengruppe.
Bei der Gruppenplanung hat der Nice-Wert eines Threads Auswirkungen auf Planungsentscheidungennur relativ zu anderen Threads in der gleichen Taskgruppe. Dies hat einige überraschende Konsequenzen hinsichtlich der traditionellen Semantik des Nice-Werts auf UNIX-Systemen. Insbesondere wenn die automatische Gruppierung aktiviert ist (was in verschiedenen Distributionen die Standardeinstellung ist), nice(1)hat die Verwendung auf einen Prozess nur Auswirkungen auf die Planung relativ zu anderen Prozessen, die in derselben Sitzung ausgeführt werden (normalerweise: im selben Terminalfenster).
Umgekehrt gilt: Bei zwei Prozessen, die (beispielsweise) die einzigen CPU-gebundenen Prozesse in unterschiedlichen Sitzungen sind (z. B. unterschiedliche Terminalfenster, deren Jobs jeweils an unterschiedliche Autogruppen gebunden sind), hat die Änderung des Nice-Werts des Prozesses in einer der Sitzungen keine Auswirkungen auf die Entscheidungen des Schedulers in Bezug auf den Prozess in der anderen Sitzung.
Wenn Sie verhindern möchten, dass die automatische Gruppierung das nicehier beschriebene traditionelle Verhalten beeinträchtigt, können Sie die Funktion deaktivieren.
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
Beachten Sie jedoch, dass dadurch auch die Vorteile der Desktop-Interaktivität deaktiviert werden, die durch die Autogroup-Funktion bereitgestellt werden sollten (siehe oben).
Die Autogruppe bietet ein gutes Preis-Leistungs-Verhältnis
Die Autogroup-Mitgliedschaft eines Prozesses kann über die Datei angezeigt werden /proc/[pid]/autogroup:
$ cat /proc/1/autogroup
/autogroup-1 nice 0
Mit dieser Datei kann auch die einer Autogroup zugewiesene CPU-Bandbreite geändert werden. Dies geschieht, indem eine Zahl im „Nice“-Bereich in die Datei geschrieben wird, um den Nice-Wert der Autogroup festzulegen. Der zulässige Bereich reicht von +19 (niedrige Priorität) bis -20 (hohe Priorität).
Die Nice-Einstellung der Autogruppe hat dieselbe Bedeutung wie der Nice-Wert des Prozesses, gilt jedoch für die Verteilung der CPU-Zyklen auf die Autogruppe als Ganzes, basierend auf den relativen Nice-Werten anderer Autogruppen. Für einen Prozess innerhalb einer Autogruppe sind die CPU-Zyklen, die er erhält, ein Produkt des Nice-Werts der Autogruppe (im Vergleich zu anderen Autogruppen) und des Nice-Werts des Prozesses (im Vergleich zu anderen Prozessen in derselben Autogruppe).