threads-max est le nombre maximum de threads que le noyau peut utiliser à la fois dans tout le système Le paramètre de noyau à définir. La valeur qui peut être définie pour ce paramètre est nettement supérieure à MAX_THREADS. Jusqu'à récemment, il y avait une régression selon laquelle seules de petites valeurs pouvaient être définies. Plus précisément, du noyau-4.0 (avril 2015) au noyau-5.4-rc3 (octobre 2019) Une telle situation perdure. Cela a été corrigé dans kernel-5.4.
Comportement à l'ancienne (testé dans un environnement de 4 Go de RAM) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823
noyau avec régression (testé dans un environnement de 4 Go de RAM) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 31348
La limite supérieure qui peut être définie dans le noyau est automatiquement définie en fonction de la taille de la mémoire réelle. C'est une opération bruyante qui m'a fait décider. Si l'application n'ajuste pas ce paramètre Cela aurait été un problème dans un environnement où cela ne pouvait pas fonctionner.
Un e-mail comme celui-ci a été envoyé à LKML et la discussion a commencé. .. .. .. 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.
Traduction libre: "Mon client réécrit la valeur saisie par threads-max avec un réglage automatique. J'ai trouvé que cela fonctionnait, mais quelle est l'intention du patch 16db3d3f1170? "
Réponses du développeur 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.
Traduction libre: set_max_threads () limite la limite supérieure de thread à 1/8 de RAM. Il n'arrive plus que la mémoire soit remplie de données de thread et que le système se bloque!
Les ingénieurs de SUSE répondent et disent 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.
Traduction gratuite: c'est ce que décide l'administrateur. C'est pourquoi il existe des outils de mesure comme memcg.
You do not change the software to overcome artificial bounds based on guessing.
Traduction libre: n'effectuez aucune modification définissant une limite supérieure par supposition arbitraire.
Un autre ingénieur 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).
Traduction gratuite: Le comportement qui n'a pas changé depuis le 2.6.12-rc2, que j'ai commencé à gérer avec git, a changé en raison du patch.
Limiting threads_max to the auto-scaling value is a regression.
Traduction libre: c'est la régression qui ajuste la valeur d'entrée de threads-max à la valeur de mise à l'échelle automatique.
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")
Traduction gratuite: Nous proposons de revenir sur le patch.
Andrew Morton, viens dire un mot https://lkml.org/lkml/2019/9/19/748 I agree, based on what I'm seeing in this thread.
Traduction libre: j'ai vu ce fil, mais je suis d'accord pour revenir.
Ainsi, [b0f53dbc4bc4c371f38](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0f53dbc4bc4c371f38b14c391095a3bb8a0lbb40.c3910cta3bb8a0lbb40.c (ne pas écraser) max. Un patch appelé fourni par l'espace utilisateur) est entré dans le noyau principal Le patch a été rétroporté vers la version stable ci-dessous.
Mainline 5.4 stable 5.3.7 stable 4.19.80 stable 4.14.150 stable 4.9.197 stable 4.4.197
Dans ces versions du noyau, # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823 Il est revenu à l'ancienne opération.
Avec le correctif rétroporté sur la relase stable, le noyau Fedora 31 a également un correctif thread-max.
c'est tout
Recommended Posts