> On Sat, 28 Feb 1998, Chris Wedgwood wrote:
>
> > (2) If we are to allow random PIDs, then on a moderately busy system, PID
> > re-use (within a short amount of time) is going to occur, and a highly
> > loaded really busy systems its going to occur fairly often....
>
> It's only when it happens in less than 1 second that it's an issue. Last
> I checked even Linux can't fork 16k times per second. But next year or
> the year after that's not an unreasonable figure given hardware and
> software improvements.
once shared page tables are implemented (eg. 90% of forked code uses the
very same low-address memory layout) we should see a ~5-fold improvement
in static fork() numbers. fork() could be close to clone() in terms of
latency, barring the root page table and the unevitable stack fault (which
"stack fault" is there for the clone() case as well, but it's done "in
advance"). We dont even need a static vfork() that way, i think.
Unfortunately it's a quite difficult task and i think Alan Cox once
mentioned that earlier P5's have an errata in this area?
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu