Dlaczego maksymalny PID w 64-bitowym systemie Linux 2 ^ 22?

Dlaczego nie 2 ^ 62, 2 ^ 31 lub cokolwiek innego?

Jaka jest maksymalna wartość identyfikatora procesu?

linux process

— babcia
źródło

To jest? Jakie jest twoje źródło?

— muru

unix.stackexchange.com/questions/16883/…

— babcia

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

To wydaje się być całkowicie arbitralnym wyborem. To może być cokolwiek, ale ktoś ¹ 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.

¹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 :

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

~~Jednak Ingo tylko dodał DEFAULT_PID_MAX. PID_MAX_LIMITzostał dodany przez Linusa Torvaldsa w 2.5.37 :~~

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

Okazuje się, że źle odczytałem dziennik zmian.

Zmiany znajdują się w zestawie łatek 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.

— muru
źródł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

@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

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.

— CVn