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

[Chris Snook]

Chris Snook wrote:
> Linus Torvalds wrote:
> > On Thu, 5 Apr 2007, Robin Holt wrote:
> > > For testing, Jack Steiner create the following patch.  All it does
> > > is moves tasks which are transitioning to the zombie state from where
> > > they are in the children list to the head of the list.  In this way,
> > > they will be the first found and reaping does speed up.  We will still
> > > do a full scan of the list once the rearranged tasks are all removed.
> > > This does not seem to be a significant problem.
> >
> > I'd almost prefer to just put the zombie children on a separate list. 
> > I wonder how painful that would be..
> >
> > That would still make it expensive for people who use WUNTRACED to get 
> > stopped children (since they'd have to look at all lists), but maybe 
> > that's not a big deal.
>
> Shouldn't be any worse than it already is.
>
> > Another thing we could do is to just make sure that kernel threads 
> > simply don't end up as children of init. That whole thing is silly, 
> > they're really not children of the user-space init anyway. Comments?
> >
> >         Linus
>
> Does anyone remember why we started doing this in the first place?  I'm 
> sure there are some tools that expect a process tree, rather than a 
> forest, and making it a forest could make them unhappy.
>
> The support angel on my shoulder says we should just put all the kernel 
> threads under a kthread subtree to shorten init's child list and 
> minimize impact.  The hacker devil on my other shoulder says that with 
> usermode helpers, containers, etc. it's about time we treat it as a 
> tree, and any tools that have a problem with that need to be fixed.
>
> -- Chris

Err, that should have been "about time we treat it as a forest".

-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/