On Thu, 8 Aug 2002, Hubertus Franke wrote:
>
> That is true. All was done under the 16-bit assumption
> My hunch is that the current algorithm might actually work quite well
> for a sparsely populated pid-space (32-bits).
I agree.
So let's just try Andries approach, suggested patch as follows..
(yeah, silly mask and MAX_PID, but since even the kernel uses signed
integers for some of it, this way it never gets close to being an issue).
Linus
----
--- 1.2/include/linux/threads.h Tue Feb 5 07:23:04 2002
+++ edited/include/linux/threads.h Thu Aug 8 14:58:28 2002
@@ -19,6 +19,7 @@
/*
* This controls the maximum pid allocated to a process
*/
-#define PID_MAX 0x8000
+#define PID_MASK 0x3fffffff
+#define PID_MAX (PID_MASK+1)
#endif
===== kernel/fork.c 1.57 vs edited =====
--- 1.57/kernel/fork.c Tue Jul 30 15:49:20 2002
+++ edited/kernel/fork.c Thu Aug 8 15:00:16 2002
@@ -142,7 +142,7 @@
return 0;
spin_lock(&lastpid_lock);
- if((++last_pid) & 0xffff8000) {
+ if((++last_pid) & ~PID_MASK) {
last_pid = 300; /* Skip daemons etc. */
goto inside;
}
@@ -157,7 +157,7 @@
p->tgid == last_pid ||
p->session == last_pid) {
if(++last_pid >= next_safe) {
- if(last_pid & 0xffff8000)
+ if(last_pid & ~PID_MASK)
last_pid = 300;
next_safe = PID_MAX;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:18 EST