On Tue, Sep 10, 2002 at 11:54:23AM +0200, Andries Brouwer wrote:
> On Mon, Sep 09, 2002 at 03:39:56PM -0700, jw schultz wrote:
>
> > The current repeated scanning is awful.
>
> I don't know what the problem is. The present scheme is very
> efficient on the average (since the pid space is very large,
> much larger than the number of processes, this scan is hardly
> ever done). All proposed alternatives are clumsy, incorrect,
> and much less efficient.
The scan itself i don't mind. It is the rescan that bothers
me. That is bother as in almost, but not quite, an itch.
"Awful" is perhaps an overstatement. I agree the space
should be sparse enough to make rescans infrequent and i
have trouble imagining what these systems must be like that
the rescanning actually loops interminably. Increasing
PID_MAX should make the pid space sparse enough to make the
problem implausible.
I was just responding to the frequent discussions of
"get_pid hang" and when i looked at get_pid said "yuck".
One of the bigger problems i have with the scan is the very
idea that there are pids that cannot be used because they
are still referenced but don't exist. That sounds lax to
me. I can understand the advantage of it. The only place
it seems to impact is get_pid. Keeping the task structs
around would mean coping with them in several other places.
It does occur to me that there could be some advantage to
having these terminated session, thread and process group
leaders show up in ps.
Well, i've put in my $0.02 plus interest.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - 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:22 EST