Pourquoi le PID maximum dans un système Linux 64 bits 2 ^ 22?

Pourquoi pas 2 ^ 62, ou 2 ^ 31 ou autre chose?

Quelle est la valeur maximale de l'ID de processus?

linux process

— grand-mère
source

Il est? Quelle est ta source?

— muru

unix.stackexchange.com/questions/16883/…

— grand

C'est très spécifique à Linux. Elle ne s'applique pas à Unix en général.

— muru

J'aurais préféré utiliser un entier 64 bits complet, de cette façon, vous pourriez garantir qu'ils ne seront jamais réutilisés. La réutilisation conduit à des conditions de concurrence où la signification d'un ID change entre le moment où vous l'obtenez et l'utilisez.

— CodesInChaos

Cela semble être un choix purement arbitraire. Cela pourrait être n'importe quoi, mais quelqu'un ^{1 a} estimé que 4 millions suffisaient. Utilisez la source :

/*
 * A maximum of 4 million PIDs should be enough for a while.
 * [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see futex.h.]
 */
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
    (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))

L'histoire sur git ne semble remonter qu'à 2005, et la valeur a été au moins aussi longue.

¹ Le manpage dit que /proc/sys/kernel/pid_maxa été ajouté à 5.2.34, et en regardant le changelog , il semble que la personne était Ingo Molnar :

<mingo@elte.hu>
    [PATCH] pid-max-2.5.33-A0

    This is the pid-max patch, the one i sent for 2.5.31 was botched.  I
    have removed the 'once' debugging stupidity - now PIDs start at 0 again.
    Also, for an unknown reason the previous patch missed the hunk that had
    the declaration of 'DEFAULT_PID_MAX' which made it not compile ...

~~Cependant, Ingo a seulement ajouté DEFAULT_PID_MAX. PID_MAX_LIMITa été ajouté par Linus Torvalds en 2.5.37 :~~

~~<torvalds@home.transmeta.com> Make pid_max grow dynamically as needed.~~

Il s'avère que j'ai mal lu le journal des modifications.

Les changements sont dans le patchset 2.5.37 :

diff -Nru a/include/linux/threads.h b/include/linux/threads.h
--- a/include/linux/threads.h   Fri Sep 20 08:20:41 2002
+++ b/include/linux/threads.h   Fri Sep 20 08:20:41 2002
@@ -17,8 +17,13 @@
 #define MIN_THREADS_LEFT_FOR_ROOT 4

 /*
- * This controls the maximum pid allocated to a process
+ * This controls the default maximum pid allocated to a process
  */
-#define DEFAULT_PID_MAX 0x8000
+#define PID_MAX_DEFAULT 0x8000
+
+/*
+ * A maximum of 4 million PIDs should be enough for a while:
+ */
+#define PID_MAX_LIMIT (4*1024*1024)

 #endif

C'est aussi loin que mes compétences en recherche me permettent.

Grâce à @hobbs, il semble qu'Ingo soit quelqu'un après tout. Le patch que j'ai cité ci-dessus a d'abord été envoyé par lui. Du post LKML qui l' accompagne:

l'empreinte mémoire du nouvel allocateur PID évolue dynamiquement avec / proc / sys / kernel / pid_max: les 32K PID par défaut provoquent une allocation 4K, un pid_max de 1 million provoque une empreinte de 128K. La limite absolue actuelle pour pid_max est de 4 millions de PID - cela n'entraîne aucune allocation dans le noyau, les bitmaps sont des temps d'exécution alloués à la demande. La table pidmap occupe 512 octets.

Il y a eu une discussion animée sur le fait d'avoir des limites plus élevées, mais il semble que rien n'en soit finalement sorti.

— muru
source

Vous pouvez obtenir un dépôt git avec une histoire plus profonde de Linux, adapté à l'archéologie, en utilisant les instructions sur stackoverflow.com/questions/3264283/… . Cela apparaît a5b5f6a "[PATCH] generic-pidhash-2.5.36-J2, BK-curr" par Ingo Molnar, visible ici sur LWN .

— hobbs

@hobbs génial! Il s'agit donc d'Ingo Molnar après tout. Je me demande pourquoi Linus s'est approprié le changelog.

— muru

@muru: Je crois que BitKeeper ne supporte pas la distinction entre committer et author, c'était l'une des leçons que Linus a appliquées quand il a conçu Git. IIRC, Ingo a refusé d'utiliser BitKeeper, il a donc envoyé des correctifs par courrier électronique, et ils ont été mal attribués dans le ChangeLogs généré automatiquement au committer, car BitKeeper n'a pas de notion distincte d'auteur. C'est ma supposition de toute façon.

— Jörg W Mittag

@ JörgWMittag possible. Maintenant, je pense que j'ai mal lu le journal des modifications et ce bit pourrait concerner un patch différent.

— muru

La citation vers la fin de cette réponse indique que la raison de ne pas choisir une valeur arbitrairement grande est les contraintes de mémoire. À 128 Ko de RAM pour 1 M de PID, même en utilisant 63 bits (en laissant le bit de signe), si je ne bousculais pas les calculs, j'aurais besoin d'un million de To de RAM pour juste la table PID. Un peu trop pour les systèmes actuels.

— un CVn du