Messages in this thread | | | Subject | Re: [PATCH] Linux-2.5 fix/improve get_pid() | From | Hubertus Franke <> | Date | Thu, 8 Aug 2002 17:43:30 -0400 |
| |
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/
| |