Eso es muy específico de Linux. No se aplica a Unix en general.
muru
Hubiera preferido usar un número entero de 64 bits, de esa manera podría garantizar que nunca se reutilizarían. La reutilización conduce a condiciones de carrera donde el significado de una ID cambia entre el momento en que la obtienes y la usas.
CodesInChaos
Respuestas:
34
Parece ser una elección puramente arbitraria. Podría ser cualquier cosa, pero alguien 1 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.
1 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 :
<[email protected]>
[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 :
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.
Puede obtener un repositorio de git con una historia más profunda de Linux, adecuado para la arqueología, utilizando las instrucciones en stackoverflow.com/questions/3264283/… . Eso muestra a5b5f6a "[PATCH] generic-pidhash-2.5.36-J2, BK-curr" por Ingo Molnar, visible aquí en LWN .
hobbs
@hobbs increíble! Entonces es de Ingo Molnar después de todo. Me pregunto por qué Linus tomó posesión en el registro de cambios.
muru
1
@muru: Creo que BitKeeper no admite la distinción entre committer y autor, esa fue una de las lecciones que Linus aplicó cuando diseñó Git. IIRC, Ingo se negó a usar BitKeeper, por lo que envió parches por correo, y se atribuyeron erróneamente en los ChangeLogs generados automáticamente al confirmador, porque BitKeeper no tiene una noción separada de autoría. Esa es mi suposición de todos modos.
Jörg W Mittag
@ JörgWMittag posible. Ahora estoy pensando que leí mal el registro de cambios y ese bit podría tratarse de un parche diferente.
muru
3
La cita cerca del final de esta respuesta indica que la razón para no elegir un valor arbitrariamente grande son las restricciones de memoria. Con 128 KB de RAM por 1 M de PID, usar incluso 63 bits (dejando el bit de signo) requeriría, si no fallara las matemáticas, un millón de TB de RAM solo para la tabla PID. Un poco alto para los sistemas actuales.
Respuestas:
Parece ser una elección puramente arbitraria. Podría ser cualquier cosa, pero alguien 1 sintió que 4 millones son suficientes. Usa la fuente :
La historia de git solo parece remontarse hasta 2005, y el valor ha sido al menos tan largo.
1 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 :Sin embargo, Ingo solo agregóDEFAULT_PID_MAX.PID_MAX_LIMITfue agregado por Linus Torvalds en 2.5.37 :Resulta que leí mal el registro de cambios.
Los cambios están en el parche 2.5.37 :
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:
Hubo una acalorada discusión sobre tener límites más altos, pero parece que al final no salió nada.
fuente