Чому максимальна PID в 64-бітній системі Linux 2 ^ 22?


22

Чому б не 2 ^ 62, або 2 ^ 31 чи щось інше?

Яке максимальне значення ідентифікатора процесу?


2
Це є? Яке джерело?
муру


Це дуже специфічно для Linux. Це не стосується Unix взагалі.
муру

Я вважаю за краще використовувати ціле 64-бітове ціле число, таким чином ви можете гарантувати, ніж вони ніколи не будуть використані повторно. Повторне використання призводить до перегонових умов, коли значення ідентифікатора змінюється між часом, коли ви його отримуєте та використовуєте.
CodesInChaos

Відповіді:


34

Здається, це суто довільний вибір. Це може бути що завгодно, але хто - то один відчував 4000000 достатньо. Використовуйте джерело :

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

Історія, що стосується git, лише здається, що сягає 2005 року, і цінність цього принаймні довга.


1 сторінка керівництво каже , що /proc/sys/kernel/pid_maxбуло додано в 2.5.34, і , дивлячись на список змін , схоже , що хто - то був Інго Молнар :

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

Однак Інго лише додав DEFAULT_PID_MAX. PID_MAX_LIMITдодав Лінус Торвальдс в 2.5.37 :

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

Виявляється, я неправильно прочитав журнал змін.

Зміни містяться в патчеті 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

Це настільки, наскільки мене здобувають мої пошукові навички.


Завдяки @hobbs, здається, Ingo все-таки хтось . Патч, який я цитував вище, вперше був надісланий ним. З повідомлення LKML, що супроводжує його:

Слід пам’яті нового аллокатора PID динамічно масштабується з / proc / sys / kernel / pid_max: PID-адреси 32K за замовчуванням викликають розподіл 4K, pid_max в 1 мільйон викликає слід 128K. Поточний абсолютний ліміт для pid_max становить 4 мільйони PID - це не спричиняє жодного розподілу в ядрі, растрові карти - це час, призначений для попиту. Таблиця pidmap займає 512 байт.

Була гостра дискусія щодо того, щоб мати більш високі межі, але, схоже, з цього нічого не вийшло.


2
Ви можете отримати git repo з більш глибокою історією Linux, що підходить для археології, скориставшись інструкціями на сайті stackoverflow.com/questions/3264283/… . Це виходить a5b5f6a "[PATCH] generic-pidhash-2.5.36-J2, BK-curr" від Ingo Molnar, який можна переглянути тут на LWN .
варення

@hobbs дивовижно! Так це все-таки від Інго Молнар. Цікаво, чому Лінус взяв право власності на журнал змін.
муру

1
@muru: Я вважаю, що BitKeeper не підтримує відмінності між виконавцем та автором, це було одним із уроків, які застосовував Лінус, коли розробляв Git. IIRC, Інго відмовився від використання BitKeeper, тому він надсилав патчі за пошту, і вони неправильно розподілялися в автоматично створених ChangeLogs до комітента, оскільки BitKeeper не має окремого поняття про авторство. Це я все-таки здогадуюсь.
Йорг W Міттаг

@ JörgWMittag можливий. Тепер я думаю, що я неправильно прочитав журнал змін, і цей біт може стосуватися іншого виправлення.
муру

3
Цитата в кінці цієї відповіді вказує на те, що причиною не набору довільно великого значення є обмеження пам’яті. При 128 Кбайт оперативної пам’яті на 1М PID, використовуючи навіть 63 біти (залишаючи бітовий знак), якщо я не отримаю математику, знадобиться мільйон ТБ оперативної пам’яті лише для таблиці PID. Трохи на високій стороні для поточних систем.
CVn
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.