Messages in this thread |  | | | Date | Tue, 10 Apr 2007 17:06:50 +0200 | | From | Ingo Molnar <> | | Subject | Re: init's children list is long and slows reaping children. |
| |
* Eric W. Biederman <ebiederm@xmission.com> wrote:
> > on a second thought: the p->children list is needed for the whole > > child/parent task tree, which is needed for sys_getppid(). > > Yes, something Oleg said made me realize that. > > As long as the reparent isn't to complex it isn't required that we > have exactly one list . > > > The question is, does anything require us to reparent to within the > > same thread group? > > I think my head is finally on straight about this question. > > Currently there is the silly linux specific parent death signal > (pdeath_signal). Oleg's memory was a better than mine on this score. > > However there is no indication that the parent death signal being sent > when a thread leader dies is actually correct, or even interesting. It > probably should only be sent when getppid changes. > > So with pdeath_signal fixed that is nothing that requires us to > reparent within the same thread group. > > I'm trying to remember what the story is now. There is a nasty race > somewhere with reparenting, a threaded parent setting SIGCHLD to > SIGIGN, and non-default signals that results in an zombie that no one > can wait for and reap. It requires being reparented twice to trigger. > > Anyway it is a real mess and if we can remove the stupid multi-headed > child lists things would become much simpler and the problem could not > occur. > > Plus the code would become much simpler... > > utrace appears to have removed the ptrace_children list and the > special cases that entailed.
so ... is anyone pursuing this? This would allow us to make sys_wait4() faster and more scalable: no tasklist_lock bouncing for example.
Ingo - 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/
|  |