On Wed, Sep 11, 2002 at 06:54:47PM -0700, Andrew Morton wrote:
> Andries Brouwer wrote:
> >
> > ...
> > Again. We have 2^30 = 10^9 pids. In reality there are fewer than 10^4
> > processes. So once in 10^5 pid allocations do we make a scan over
> > these 10^4 processes,
>
> Inside tasklist_lock? That's pretty bad from a latency point of
> view. A significant number of users would take the slower common
> case to avoid this.
That would be unwise of all these users.
As soon as people have so many processes that this becomes a problem,
then instead of making things slower they should make things faster
still, at the cost of a little bit of extra code.
Similarly, people that need real-time guarantees will probably add
that extra code.
Now that things are ten thousand times better than they were very
recently I find it a bit surprising that people worry. But yes, when
needed it is very easy to come with further improvements.
Once people stand up and say that they need Linux machines with 10^6
processes, or with 10^4 processes and real time guarantees, then we
must have a discussion about data structures, and a discussion about
standards.
The standards part is this: what values are allowed for p->pgrp,
p->tgid, p->session? Can these be arbitrary numbers? Or can the
positive values among them be restricted to pid's?
If this restriction can be imposed we can be slightly more efficient.
But these future discussions must not be about get_pid() but about
task list handling, scheduling, sending signals, all places that
today have for_each_task(p) ...
Andries
-
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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:30 EST