Perché il PID massimo in un sistema Linux a 64 bit 2 ^ 22?

Perché non 2 ^ 62 o 2 ^ 31 o qualcos'altro?

Qual è il valore massimo dell'ID processo?

linux process

— nonna
fonte

È? Qual è la tua fonte?

— muru,

unix.stackexchange.com/questions/16883/…

— nonna

Questo è molto specifico per Linux. Non si applica a Unix in generale.

— muru,

Avrei preferito usare un intero a 64 bit, in questo modo potresti garantire che non vengano mai riutilizzati. Il riutilizzo porta a condizioni di competizione in cui il significato di un ID cambia tra il momento in cui lo ottieni e lo usi.

— CodesInChaos,

Sembra essere una scelta puramente arbitraria. Potrebbe essere qualsiasi cosa, ma qualcuno ¹ feltro 4 milioni è sufficiente. Usa la fonte :

/*
 * 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))

La storia su Git sembra risalire solo al 2005, e il valore è stato almeno per tanto tempo.

¹ La pagina di manuale dice che /proc/sys/kernel/pid_maxè stata aggiunta nel 2.5.34, e guardando il changelog , sembra che il qualcuno era 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 ...

~~Tuttavia, Ingo ha solo aggiunto DEFAULT_PID_MAX. PID_MAX_LIMITè stato aggiunto da Linus Torvalds nella 2.5.37 :~~

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

A quanto pare, ho letto male il log delle modifiche.

Le modifiche sono nel 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

Questo è quanto mi capiscono le mie capacità di ricerca.

Grazie a @hobbs, sembra che Ingo sia qualcuno dopo tutto. La patch che ho citato sopra è stata inizialmente inviata da lui. Dal post LKML che lo accompagna:

il footprint di memoria del nuovo allocatore PID si ridimensiona in modo dinamico con / proc / sys / kernel / pid_max: i PID 32K predefiniti causano un'allocazione 4K, un pid_max di 1 milione provoca un footprint di 128K. L'attuale limite assoluto per pid_max è di 4 milioni di PID - questo non causa alcuna allocazione nel kernel, le bitmap sono runtime allocate su richiesta. La tabella pidmap occupa 512 byte.

C'è stata una discussione accesa sull'avere limiti più alti, ma alla fine sembra che non ne sia uscito nulla.

— Muru
fonte

Puoi ottenere un repository git con una storia più profonda di Linux, adatta per l'archeologia, usando le istruzioni su stackoverflow.com/questions/3264283/… . Viene visualizzato a5b5f6a "[PATCH] generic-pidhash-2.5.36-J2, BK-curr" di Ingo Molnar, visualizzabile qui su LWN .

— Hobbs,

@hobbs fantastico! Quindi, dopo tutto, viene da Ingo Molnar. Mi chiedo perché Linus sia diventato proprietario del log delle modifiche.

— muru,

@muru: credo che BitKeeper non supporti la distinzione tra committer e autore, questa è stata una delle lezioni che Linus ha applicato quando ha progettato Git. IIRC, Ingo ha rifiutato di utilizzare BitKeeper, quindi ha inviato patch per posta e sono stati erroneamente attribuiti nei ChangeLog generati automaticamente al committer, perché BitKeeper non ha una nozione separata di paternità. Questa è la mia ipotesi comunque.

— Jörg W Mittag,

@ JörgWMittag possibile. Ora sto pensando di aver letto male il log delle modifiche e quella parte potrebbe riguardare una patch diversa.

— Muru,

La citazione vicino alla fine di questa risposta indica che la ragione per non scegliere un valore arbitrariamente grande è i vincoli di memoria. A 128 KB di RAM per 1 M di PID, l'utilizzo di anche 63 bit (lasciando il bit di segno), se non avessi fallito la matematica, richiederebbe un milione di TB di RAM solo per la tabella PID. Un po 'alto per i sistemi attuali.

— un CVn