¿Por qué el PID máximo en un sistema Linux de 64 bits es 2 ^ 22?

¿Por qué no 2 ^ 62, o 2 ^ 31 o cualquier otra cosa?

¿Cuál es el valor máximo de la ID del proceso?

Parece ser una elección puramente arbitraria. Podría ser cualquier cosa, pero alguien ¹ sintió que 4 millones son suficientes. Usa la fuente :

/*
 * 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 historia de git solo parece remontarse hasta 2005, y el valor ha sido al menos tan largo.

¹ La página de manual dice que /proc/sys/kernel/pid_maxse agregó en 2.5.34, y mirando el registro de cambios , parece que alguien era Ingo Molnár :

<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 ...

Sin embargo, Ingo solo agregó DEFAULT_PID_MAX. PID_MAX_LIMITfue agregado por Linus Torvalds en 2.5.37 :

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

Resulta que leí mal el registro de cambios.

Los cambios están en el parche 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

Eso es lo que mis habilidades de búsqueda me llevan.

Gracias a @hobbs, parece que Ingo es alguien después de todo. El parche que cité arriba fue enviado primero por él. De la publicación LKML que lo acompaña:

la huella de memoria del nuevo asignador PID se escala dinámicamente con / proc / sys / kernel / pid_max: los PID de 32K predeterminados causan una asignación de 4K, un pid_max de 1 millón causa una huella de 128K. El límite absoluto actual para pid_max es de 4 millones de PID, esto no causa ninguna asignación en el núcleo, los mapas de bits son tiempos de ejecución asignados a la demanda. La tabla pidmap ocupa 512 bytes.

Hubo una acalorada discusión sobre tener límites más altos, pero parece que al final no salió nada.