ทำไม PID สูงสุดในระบบ Linux 64 บิต 2 ^ 22


22

ทำไมไม่ 2 ^ 62 หรือ 2 ^ 31 หรืออย่างอื่นล่ะ

ค่าสูงสุดของ ID กระบวนการคืออะไร


2
มันคือ? แหล่งที่มาของคุณคืออะไร
muru


เฉพาะ Linux เท่านั้น มันไม่ได้ใช้กับ Unix โดยทั่วไป
muru

ฉันจะต้องใช้จำนวนเต็ม 64 บิตเต็มรูปแบบวิธีที่คุณสามารถรับประกันได้กว่าที่พวกเขาจะไม่ถูกนำมาใช้ซ้ำ การใช้ซ้ำจะนำไปสู่เงื่อนไขการแข่งขันที่ความหมายของการเปลี่ยนแปลง ID ระหว่างเวลาที่คุณได้รับและใช้งาน
CodesInChaos

คำตอบ:


34

มันดูเหมือนจะเป็นทางเลือกโดยพลการอย่างแท้จริง อาจเป็นอะไรก็ได้ แต่บางคนที่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))

ประวัติศาสตร์เกี่ยวกับคอมไพล์ดูเหมือนจะย้อนกลับไปจนถึงปีพ. ศ. 2548 และคุณค่าก็คืออย่างน้อยก็นาน


1 manpageบอกว่า/proc/sys/kernel/pid_maxถูกเพิ่มเข้ามาใน 2.5.34 และมองไปที่การเปลี่ยนแปลงจะมีลักษณะเหมือนใครบางคนเป็น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 ...

อย่างไรก็ตาม Ingo DEFAULT_PID_MAXเพิ่มเฉพาะ PID_MAX_LIMITถูกเพิ่มโดย Linus 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 ที่มาพร้อมกับมัน:

footprint หน่วยความจำของตัวจัดสรร PID ใหม่จะปรับขนาดแบบไดนามิกด้วย / proc / sys / kernel / pid_max: ค่าเริ่มต้น 32K PIDs ทำให้เกิดการจัดสรร 4K, pid_max 1 ล้านทำให้เกิดรอย 128K ขีด จำกัด สัมบูรณ์ปัจจุบันสำหรับ pid_max คือ 4 ล้าน PID - นี่ไม่ทำให้เกิดการจัดสรรใด ๆ ในเคอร์เนลบิตแมปเป็นรันไทม์ที่จัดสรรตามความต้องการ ตาราง pidmap ใช้เวลามากถึง 512 ไบต์

มีการถกเถียงกันอย่างดุเดือดเกี่ยวกับการมีขีด จำกัด ที่สูงขึ้น แต่ดูเหมือนว่าไม่มีอะไรออกมาในตอนท้าย


2
คุณสามารถรับ repo คอมไพล์ที่มีประวัติของ Linux ที่ลึกกว่า, เหมาะสำหรับนักโบราณคดี, โดยใช้คำแนะนำที่stackoverflow.com/questions/3264283/… . ที่ผลัดกันขึ้น a5b5f6a "[PATCH] ทั่วไป-pidhash-2.5.36-J2, BK-curr" โดย Ingo Molnar, สามารถดูได้ที่นี่ใน LWN
ฮอบส์

@ ฮอบส์สุดยอดมาก! ดังนั้นจึงมาจาก Ingo Molnar หลังจากทั้งหมด ฉันสงสัยว่าทำไมไลนัสถึงเป็นเจ้าของในการเปลี่ยนแปลง
muru

1
@muru: ฉันเชื่อว่า BitKeeper ไม่สนับสนุนความแตกต่างระหว่างผู้ส่งและผู้เขียนนั่นเป็นหนึ่งในบทเรียนที่ Linus ใช้เมื่อเขาออกแบบ Git IIRC, Ingo ปฏิเสธที่จะใช้ BitKeeper ดังนั้นเขาจึงส่งแพตช์ต่ออีเมลและพวกเขาได้รับข้อมูลผิดพลาดใน ChangeLogs ที่สร้างขึ้นโดยอัตโนมัติไปยังผู้ส่งเนื่องจาก BitKeeper ไม่มีแนวคิดเรื่องการเขียนที่แยกต่างหาก นั่นคือการคาดเดาของฉัน
Jörg W Mittag

@ JörgWMittagที่เป็นไปได้ ตอนนี้ฉันคิดว่าฉันเข้าใจผิดรายการเปลี่ยนแปลงและบิตนั้นอาจเกี่ยวกับแพตช์อื่น
muru

3
เครื่องหมายคำพูดใกล้ถึงจุดสิ้นสุดของคำตอบนี้บ่งชี้ว่าเหตุผลที่ไม่เลือกค่าที่มีขนาดใหญ่ตามอำเภอใจคือข้อ จำกัด ของหน่วยความจำ ที่ 128 KB RAM ต่อ 1M PID โดยใช้แม้แต่ 63 บิต (ทิ้งเครื่องหมายบิต) หากฉันไม่ได้คำนวณทางคณิตศาสตร์ต้องใช้ RAM เป็นล้าน TB สำหรับตาราง PID เล็กน้อยในระดับสูงสำหรับระบบปัจจุบัน
CVn
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.