Re: init's children list is long and slows reaping children.

[Chris Snook <csnook@redhat.com>]

Eric W. Biederman wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > I'm not sure anybody would really be unhappy with pptr pointing to some 
> > magic and special task that has pid 0 (which makes it clear to everybody 
> > that the parent is something special), and that has SIGCHLD set to SIG_IGN 
> > (which should make the exit case not even go through the zombie phase).
> >
> > I can't even imagine *how* you'd make a tool unhappy with that, since even 
> > tools like "ps" (and even more "pstree" won't read all the process states 
> > atomically, so they invariably will see parent pointers that don't even 
> > exist any more, because by the time they get to the parent, it has exited 
> > already.
>
> Right.  pid == 1 being missing might cause some confusing having 
> but having ppid == 0 should be fine.  Heck pid == 1 already has 
> ppid == 0, so it is a value user space has had to deal with for a
> while.
>
> In addition there was a period in 2.6 where most kernel threads
> and init had a pgid == 0 and a session  == 0, and nothing seemed
> to complain.
>
> We should probably make all of the kernel threads children of
> init_task.  The initial idle thread on the first cpu that is the
> parent of pid == 1.   That will give the ppid == 0 naturally because
> the idle thread has pid == 0.

Linus, Eric, thanks for the history lesson.  I think it's safe to say 
that anything that breaks because of this sort of change was already 
broken anyway.

If we're going to scale to an obscene number of CPUs (which I believe 
was the original motivation on this thread) then putting the dead 
children on their own list will probably scale better.

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