[lkml]   [2002]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Linux-2.5 fix/improve get_pid()

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

Should be easy to figure out.

Hubertus Franke
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003

Rik van Riel
<riel@conectiva. To: Hubertus Franke/Watson/IBM@IBMUS> cc: Andries Brouwer <>, Andrew Morton <>,
<>, <>, lkml <>, Paul Larson
08/08/2002 04:15 <>, Linus Torvalds <>
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,

"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.083 / U:16.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site