To bardzo specyficzne dla Linuksa. Nie dotyczy to ogólnie systemu Unix.
muru
Wolałbym używać pełnej 64-bitowej liczby całkowitej, w ten sposób można zagwarantować, że nigdy nie zostaną ponownie użyte. Ponowne użycie prowadzi do warunków wyścigu, w których znaczenie ID zmienia się między momentem jego zdobycia a użyciem.
CodesInChaos
Odpowiedzi:
34
To wydaje się być całkowicie arbitralnym wyborem. To może być cokolwiek, ale ktoś 1 czuł, że 4 miliony wystarczy. Użyj źródła :
/*
* 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))
Historia git wydaje się sięgać 2005 roku, a wartość była przynajmniej tak długa.
1 podręcznika mówi, że /proc/sys/kernel/pid_maxzostał dodany w 2.5.34, a patrząc w changelogu , to wygląda jakby ktoś był 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 ...
Jednak Ingo tylko dodał DEFAULT_PID_MAX. PID_MAX_LIMITzostał dodany przez Linusa Torvaldsa w 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
To tyle, o ile mnie umiejętności wyszukiwania.
Dzięki @hobbs wygląda na to, że Ingo to ktoś . Patch, który cytowałem powyżej, został po raz pierwszy wysłany przez niego. Z towarzyszącego mu postu LKML :
ślad pamięci nowego alokatora PID skaluje się dynamicznie z / proc / sys / kernel / pid_max: domyślne 32K PID powodują alokację 4K, pid_max 1 miliona powoduje ślad 128K. Obecny bezwzględny limit dla pid_max wynosi 4 miliony PID-ów - nie powoduje to żadnej alokacji w jądrze, mapy bitowe są środowiskiem wykonawczym alokowanym na żądanie. Tabela pidmap zajmuje 512 bajtów.
Odbyła się gorąca dyskusja na temat wyższych limitów, ale wydaje się, że ostatecznie nic z tego nie wyszło.
Można uzyskać repo git z głębszej historii Linux, odpowiednim dla archeologii, korzystając z instrukcji na stackoverflow.com/questions/3264283/... . To pokazuje a5b5f6a „[PATCH] generic-pidhash-2.5.36-J2, BK-curr” autorstwa Ingo Molnara, który można obejrzeć tutaj na LWN .
hobbs
@hobbs niesamowite! W końcu pochodzi z Ingo Molnar. Zastanawiam się, dlaczego Linus przejął na własność dziennik zmian.
muru
1
@muru: Uważam, że BitKeeper nie popiera rozróżnienia między autorem i autorem, to była jedna z lekcji, którą Linus zastosował, projektując Gita. IIRC, Ingo odmówił użycia BitKeepera, więc wysłał łatki na pocztę i zostały one błędnie przypisane do automatycznie generowanych dzienników zmian do osoby odpowiedzialnej, ponieważ BitKeeper nie ma odrębnego pojęcia o autorstwie. W każdym razie tak sądzę.
Jörg W Mittag
@ JörgWMittag możliwe. Teraz myślę, że źle odczytałem dziennik zmian i ten fragment może dotyczyć innej łatki.
muru
3
Cytat pod koniec tej odpowiedzi wskazuje, że powodem niezebrania arbitralnie dużej wartości są ograniczenia pamięci. Przy 128 KB RAM na 1 M PID, użycie nawet 63 bitów (pozostawiając bit znaku), gdybym nie spartaczył matematyki, wymagałoby miliona TB pamięci RAM dla samej tabeli PID. Trochę za wysoka dla obecnych systemów.
Odpowiedzi:
To wydaje się być całkowicie arbitralnym wyborem. To może być cokolwiek, ale ktoś 1 czuł, że 4 miliony wystarczy. Użyj źródła :
Historia git wydaje się sięgać 2005 roku, a wartość była przynajmniej tak długa.
1 podręcznika mówi, że
/proc/sys/kernel/pid_maxzostał dodany w 2.5.34, a patrząc w changelogu , to wygląda jakby ktoś był Ingo Molnár :Jednak Ingo tylko dodałDEFAULT_PID_MAX.PID_MAX_LIMITzostał dodany przez Linusa Torvaldsa w 2.5.37 :Okazuje się, że źle odczytałem dziennik zmian.
Zmiany znajdują się w zestawie łatek 2.5.37 :
To tyle, o ile mnie umiejętności wyszukiwania.
Dzięki @hobbs wygląda na to, że Ingo to ktoś . Patch, który cytowałem powyżej, został po raz pierwszy wysłany przez niego. Z towarzyszącego mu postu LKML :
Odbyła się gorąca dyskusja na temat wyższych limitów, ale wydaje się, że ostatecznie nic z tego nie wyszło.
źródło