lkml.org 
[lkml]   [2002]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK

This is not about 'PID space squeeze'. Every sane sysadmin sets pid_max to
a high enough value - but sure i'm all for auto-sizing it - i proposed
auto-sizing of the allocation bitmap so i have absolutely nothing against
it.

the fundamental problem is consecutive allocation of PIDs. It can and will
happen, no matter what. In fact if it doesnt happen in every minute only
every week or so it's even worse. The current get_pid() algorithm, if it
sees 32K consequtively allocated PIDs [the next time the PID counter
overflows and gets to the PID-range - with the new optimizations this can
happen within 1 second even for a pid_max of 1 million], then the current
algorithm goes into a 32K*32K loop, ie. a loop of 1 billion, which takes
32 seconds.

only an infinite PID space [pratically infinite would be 64 bits or 128
bits] solves this problem in the current algorithm, or the patch we are
proposing, which also solves some other pending problems so it's
apparently a step in the right direction. (And it also enable us to
compress the PID space to make it more readable for mere mortals - if that
matters.)

Ingo

-
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/

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