threads-max ist die maximale Anzahl von Threads, die der Kernel gleichzeitig im gesamten System verwenden kann Der zu setzende Kernel-Parameter. Der Wert, der für diesen Parameter festgelegt werden kann, ist erheblich höher als MAX_THREADS. Bis vor kurzem gab es eine Regression, bei der nur kleine Werte festgelegt werden konnten. Insbesondere von Kernel-4.0 (April 2015) bis Kernel-5.4-rc3 (Oktober 2019) Eine solche Situation hielt an. Dies wurde in Kernel-5.4 behoben.
Altmodisches Verhalten (getestet in 4 GB RAM-Umgebung) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823
Kernel mit Regression (getestet in 4 GB RAM-Umgebung) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 31348
Die Obergrenze, die im Kernel festgelegt werden kann, wird automatisch entsprechend der Größe des realen Speichers festgelegt. Es war eine laute Operation, die mich zu einer Entscheidung brachte. Wenn die Anwendung diesen Parameter nicht anpasst Es wäre ein Problem in einer Umgebung gewesen, in der es nicht funktionieren könnte.
Eine solche E-Mail wurde an LKML gesendet und die Diskussion begann. .. .. .. https://lkml.org/lkml/2019/9/17/294 Hi, I have just stmbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits") and I am really wondering what is the motivation behind the patch. We've had a customer noticing the threads_max autoscaling differences btween 3.12 and 4.4 kernels and wanted to override the auto tuning from the userspace, just to find out that this is not possible.
Why do we override user admin like that? I find it quite dubious to be honest. Especially when the auto-tunning is just a very rough estimation and it seems quite arbitrary.
Kostenlose Übersetzung: "Mein Kunde schreibt den von threads-max eingegebenen Wert neu, wobei die automatische Optimierung funktioniert. Ich fand es funktioniert, aber was ist die Absicht von Patch 16db3d3f1170? "
Entwickler antwortet https://lkml.org/lkml/2019/9/17/570 set_max_threads() sets the upper limit (max_threads_suggested) for threads such that at a maximum 1/8th of the total memory can be occupied by the thread's administrative data (of size THREADS_SIZE). On my 32 GiB system this results in 254313 threads.
With patch 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits") a user cannot set an arbitrarily high number for /proc/sys/kernel/threads-max which could lead to a system stalling because the thread headers occupy all the memory.
Kostenlose Übersetzung: set_max_threads () begrenzt die Obergrenze des Threads auf 1/8 des RAM. Es ist nicht mehr möglich, dass Ihr System blockiert, wenn der Speicher mit Thread-Daten gefüllt wird!
SUSE-Ingenieure antworten und sagen https://lkml.org/lkml/2019/9/17/589 This is still a decision of the admin to make. You can consume the memory by other means and that is why we have measures in place. E.g. memcg accounting.
Kostenlose Übersetzung: Das entscheidet der Administrator. Deshalb gibt es Messwerkzeuge wie memcg.
You do not change the software to overcome artificial bounds based on guessing.
Kostenlose Übersetzung: Nehmen Sie keine Änderungen vor, die durch willkürliche Vermutungen eine Obergrenze festlegen.
Ein anderer Ingenieur https://lkml.org/lkml/2019/9/17/705 a) The logic to set the default number of threads in a system has not changed since 2.6.12-rc2 (the start of the git history).
Kostenlose Übersetzung: Das Verhalten, das sich seit 2.6.12-rc2, das ich mit git verwaltet habe, nicht geändert hat, hat sich aufgrund des Patches geändert.
Limiting threads_max to the auto-scaling value is a regression.
Freie Übersetzung: Es ist die Regression, die den Eingabewert von threads-max auf den Wert für die automatische Skalierung anpasst.
https://lkml.org/lkml/2019/9/19/113 Any take on this Heinrich? If there really is not strong reasoning about the restricting user input then I will suggest reverting 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
Kostenlose Übersetzung: Wir schlagen vor, den Patch zurückzusetzen.
Andrew Morton Komm raus und sag ein Wort https://lkml.org/lkml/2019/9/19/748 I agree, based on what I'm seeing in this thread.
Kostenlose Übersetzung: Ich habe diesen Thread gesehen, bin aber mit dem Zurücksetzen einverstanden.
Daher ist b0f53dbc4bc4c371f38 Ein vom Userspace bereitgestellter Patch wurde in den Mainline-Kernel eingegeben Der Patch wurde in die unten stehende stabile Version zurückportiert.
Mainline 5.4 stable 5.3.7 stable 4.19.80 stable 4.14.150 stable 4.9.197 stable 4.4.197
In diesen Kernelversionen # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823 Es ist zur alten Operation zurückgekehrt.
Da der Patch auf Stable Relase zurückportiert wurde, verfügt der Fedora 31-Kernel auch über einen Thread-Max-Fix.
das ist alles
Recommended Posts