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).
A bitmap-ed based solution is not possible at that point due to space
requirements.
Should be easy to figure out.
Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
Rik van Riel
<riel@conectiva. To: Hubertus Franke/Watson/IBM@IBMUS
com.br> cc: Andries Brouwer <aebr@win.tue.nl>, Andrew Morton <akpm@zip.com.au>,
<andrea@suse.de>, <davej@suse.de>, lkml <linux-kernel@vger.kernel.org>, Paul Larson
08/08/2002 04:15 <plars@austin.ibm.com>, Linus Torvalds <torvalds@transmeta.com>
PM Subject: Re: [PATCH] Linux-2.5 fix/improve get_pid()
On Thu, 8 Aug 2002, Hubertus Franke wrote:
> Which one sounds like the best one ?
>
> Assuming that for now we have to stick to 16-bit pid_t ....
That assumption is pretty central to the debate.
I don't see the standard get_pid nor the bitmap based
get_pid scale to something larger than a 16-bit pid_t.
If we're not sure yet whether we want to keep pid_t 16
bits it might be worth putting in an algorithm that does
scale to larger numbers, if only so the switch to a larger
pid_t will be more straightforward.
kind regards,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
-
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/