Wenn ich zwei CPU-fressende Prozesse mit unterschiedlichem Nice-Level starte, z.B.
Prozess 1:
nice -19 sh -c 'while true; do :; done'
Prozess 2:
sh -c 'while :; do true; done'
(Ich habe die Reihenfolge von : geändert und true nur um die Prozesse in den Ausgaben von ps auseinanderzuhalten oder top ),
der Nice-Level scheint ignoriert zu werden und beide verbrauchen die gleiche Menge an CPU.
Die Ausgabe von top ist wie
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
8187 <user> 39 19 21.9m 3.6m 45.8 0.0 0:20.62 R sh -c while true; do :; done
8188 <user> 20 0 21.9m 3.5m 45.6 0.0 0:20.23 R sh -c while :; do true; done
[...]
(natürlich die %CPU -Werte variieren leicht von Probe zu Probe, aber im Durchschnitt scheinen sie gleich zu sein).
top zeigt, dass beide Prozesse mit unterschiedlichen netten Werten laufen, aber sie scheinen immer noch die gleiche Menge an CPU-Zeit zu bekommen.
Beide Befehle wurden von demselben Benutzer auf verschiedenen Terminals ausgeführt (beide sind Anmelde-Shells).
Wenn sie vom selben Terminal ausgeführt werden, verhalten sie sich wie erwartet:Der nettere Prozess macht Platz für den weniger netten.
Was ist der Grund? Wie kann man global auf der ganzen Maschine gute Arbeit leisten?
Anders war es einige Zeit zuvor auf eben dieser Maschine, wo Nice-Values in Ehren gehalten zu werden schienen.
Es ist eine Maschine mit einem Prozessor/einem einzelnen Kern.
Zur Information:
- Kernel:Version 4.4.5 (Stock-Kernel von Arch Linux);
uname -r:4.4.5-1-ARCH, -
/proc/cpuinfoist:processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Solo CPU U3500 @ 1.40GHz stepping : 10 microcode : 0xa0c cpu MHz : 1400.000 cache size : 3072 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 2794.46 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Akzeptierte Antwort:
Ah, es ist nicht die systemd-logind-Funktion, bei der jeder Benutzer seine eigene cgroup bekommt. Ich denke, die hier verantwortliche Änderung ist älter; Sie sind sich nur zum Verwechseln ähnlich. (Ich suchte nach „Process Group Fair Scheduling“ und dachte, es könnte etwas sein, das auf den „Process Groups“ von Unix basiert, das ich nie wirklich verstehe). Wikipedia:
Der Linux-Kernel erhielt im November 2010 einen Patch für CFS für den 2.6.38-Kernel, der den Scheduler für die Verwendung auf Desktops und Workstations gerechter gemacht hat.
Wenn eine Aufgabe __proc_set_tty() aufruft, wird der prozessweite Verweis auf die Standardgruppe gelöscht, eine neue Aufgabengruppe erstellt und der Prozess in die neue Aufgabengruppe verschoben. Kinder erben danach diese Aufgabengruppe und erhöhen ihren Refcount. Beim Beenden wird ein Verweis auf die aktuelle Aufgabengruppe gelöscht, wenn der letzte Verweis auf jede Signalstruktur gelöscht wird. Die Aufgabengruppe wird zerstört, wenn die letzte darauf verweisende Signalstruktur freigegeben wird. Wenn zum Zeitpunkt der Runqueue-Auswahl eine Aufgabe keine Cgroup-Zuweisung hat, wird ihre aktuelle Autogroup verwendet.
Die Funktion ist standardmäßig beim Booten aktiviert, wenn CONFIG_SCHED_AUTOGROUP ausgewählt ist, kann aber über die Boot-Option noautogroup deaktiviert und auch on-the-fly ein-/ausgeschaltet werden [über /proc/sys/kernel/sched_autogroup_enabled :Schreiben von Dort wird es für neu erstellte Aufgaben deaktiviert, indem Sie 1 schreiben aktiviert es.]
Die dadurch gelösten Hauptprobleme betreffen Systeme mit mehreren Kernen und mehreren CPUs (SMP), bei denen erhöhte interaktive Antwortzeiten auftreten, während andere Aufgaben ausgeführt werden, die viele Threads in diesen Aufgaben verwenden. Eine einfache Erklärung ist, dass man immer noch in der Lage sein wird, ein Video anzusehen, E-Mails zu lesen und andere typische Desktop-Aktivitäten ohne Störungen oder Abgehacktheit auszuführen, während man den Linux-Kernel oder einen ähnlichen Prozess wie das Kodieren von Videos kompiliert. Gegen diese Aussage gibt es jedoch Einwände.