Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: pid_t range question | Date | Fri, 10 Feb 2006 02:19:33 +0100 |
| |
Jesper Juhl <jesper.juhl@gmail.com> wrote:
> I can think of at least 3 ways to at least hide that cosmetic problem [of /bin/ps] > a bit. Won't solve the problem but will make it less likely that most > people will ever encounter it. > > (assuming below that we want something like 64bit pids but want to > keep pids at 5 digits as much as possible) [...] > 2. Allocate pid's as we currently do, but once we hit 99999 wrap the > pids and start allocating from free pids starting from 2 and up. only > if no pids below 99999 are free do we continue upwards and allocate > pid 100000.
2b) don't try that hard, and hopefully speed things up:
<pseudocode> for (max = 3814; /* max == 999817216 * 8 */; max = max * 8) { // the above values result from int(1000000000/8^6){,*8^6} newpid = random(max)+1; if allocate_pid(newpid) goto got_the_pid; // repeat the above in order to make it less likely // to get a high PID? I hope it's not nescensary. if (max == 999817216) // otherwise an uint32 will overflow break; } // possible here to increase the chance for a low pid but also for // long runs while searching for the first free pid: // newpid = random(99999)+1; pid_search_stop = newpid; while (++newpid != pid_search_stop) { if allocate_pid(newpid) goto got_the_pid; } got_the_pid: </pseudocode>
TOSOLVE:
Find a cheap random function.
What to do on 4294967295 allocated processes?
Eternal starvation if nearly 4294967295 are present and the right ones get stopped/started?
How to get CPU power to run 4294967295 processes?
-- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - 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/
| |