[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <461A79C4.20901@redhat.com>
Date: Mon, 09 Apr 2007 13:37:08 -0400
From: Chris Snook <csnook@...hat.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Robin Holt <holt@....com>, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org,
Jack Steiner <steiner@...ricas.sgi.com>
Subject: Re: init's children list is long and slows reaping children.
Eric W. Biederman wrote:
> Linus Torvalds <torvalds@...ux-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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists