64 비트 Linux 시스템에서 최대 PID가 2 ^ 22 인 이유는 무엇입니까?


22

왜 2 ^ 62, 2 ^ 31 또는 다른 것이 있습니까?

프로세스 ID의 최대 값은 얼마입니까?


2
그것은? 당신의 출처는 무엇입니까?
muru September


이것은 Linux에만 해당됩니다. 일반적으로 유닉스에는 적용되지 않습니다.
muru September

완전한 64 비트 정수를 사용하는 것이 좋았을 것입니다. 그런 식으로 결코 재사용되지 않을 것입니다. 재사용은 ID를 획득하고 사용하는 시간 사이에 ID의 의미가 바뀌는 경쟁 조건으로 이어집니다.
코드 InChaos

답변:


34

순전히 임의의 선택 인 것 같습니다. 그것은 무엇이든 될 수 있지만 누군가 1 백만은 충분하다고 느꼈습니다. 소스를 사용하십시오 :

/*
 * 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_max2.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_LIMITLinus Torvalds가 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를 사용하여 동적으로 확장됩니다. 기본 32K PID는 4K 할당을 발생시키고 pid_max는 1 백만이며 128K 풋 프린트를 발생시킵니다. pid_max의 현재 절대 한계는 4 백만 PID입니다. 이것은 커널에서 할당을 유발하지 않으며 비트 맵은 수요 할당 런타임입니다. pidmap 테이블은 512 바이트를 차지합니다.

더 높은 한계를 갖는 것에 대한 격렬한 토론이 있었지만 결국에는 아무것도 나오지 않은 것 같습니다.


2
stackoverflow.com/questions/3264283/… 의 지침을 사용하여 고고학에 적합한 Linux의 더 깊은 역사를 가진 git repo를 얻을 수 있습니다 . 이것은 Ingo Molnar의 a5b5f6a "[PATCH] generic-pidhash-2.5.36-J2, BK-curr"이며 LWN 에서 볼 수 있습니다 .
hobbs

@hobbs 굉장합니다! 결국 그것은 잉고 몰나에서 온 것입니다. Linus가 왜 변경 로그에서 소유권을 얻었는지 궁금합니다.
muru

1
@muru : BitKeeper는 커미터와 저자의 구별을 지원하지 않는다고 생각합니다. Linus가 Git을 디자인 할 때 적용한 교훈 중 하나였습니다. IIRC의 Ingo는 BitKeeper의 사용을 거부하여 메일 당 패치를 보냈으며 BitKeeper는 별도의 저작권 개념이 없기 때문에 자동 생성 된 ChangeLogs에서 커미터에게 잘못 귀속되었습니다. 어쨌든 내 추측이다.
Jörg W Mittag

@ JörgWMittag 가능합니다. 이제 변경 로그를 잘못 읽었으며 그 비트가 다른 패치에 관한 것일 수 있습니다.
muru

3
이 답변의 끝 부분에있는 인용 부호는 임의로 큰 값을 선택하지 않은 이유는 메모리 제약 조건임을 나타냅니다. 1M PID 당 128KB RAM에서 심지어 63 비트 (부호 비트를 남기고)를 사용하면 수학을 버리지 않으면 PID 테이블에만 백만 TB의 RAM이 필요합니다. 현재 시스템에서는 약간 높은 편입니다.
CVn
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.