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

Почему бы не 2 ^ 62, или 2 ^ 31 или что-нибудь еще?

Каково максимальное значение идентификатора процесса?

  • Как отправить запущенный процесс в тюрьму?
  • Понимание управляющего терминала
  • Как распечатать имя процесса рядом с идентификационным номером процесса в файле?
  • Как отсортировать вывод ps для поиска приоритетов в реальном времени и определить обработанную текущую очередь процесса
  • Хорошие и дочерние процессы
  • Файлы больше max (off64_t) в Solaris, например «/proc/../as»,
  • Приложение в терминале все еще работает, но не доступно напрямую
  • Какой процесс отправляет TCP SYN на Solaris 10?
  • One Solution collect form web for “Почему максимальный PID в 64-битной системе Linux 2 ^ 22?”

    Кажется, это чисто произвольный выбор. Это может быть что угодно, но кто-то 1 чувствовал, что 4 миллиона достаточно. Используйте источник :

    /* * 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 В manpage говорится, что /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 ... 

    Однако Ingo добавила только 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.hb/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, кажется, Инго – это кто-то в конце концов. Патч, который я цитировал выше, был сначала отправлен им. С сопроводительной записью LKML :

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

    Было горячее обсуждение о более высоких ограничениях, но, похоже, в конце концов ничего не получилось.

    Linux и Unix - лучшая ОС в мире.