Re: pid_t range question

[Bodo Eggert]

Jesper Juhl <jesper.juhl@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/