From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1767462AbXDFAwF (ORCPT ); Thu, 5 Apr 2007 20:52:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1767465AbXDFAwF (ORCPT ); Thu, 5 Apr 2007 20:52:05 -0400 Received: from mx1.redhat.com ([66.187.233.31]:57653 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1767462AbXDFAwD (ORCPT ); Thu, 5 Apr 2007 20:52:03 -0400 Message-ID: <46159987.6090006@redhat.com> Date: Thu, 05 Apr 2007 20:51:19 -0400 From: Chris Snook User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: Linus Torvalds CC: Robin Holt , "Eric W. Biederman" , Ingo Molnar , linux-kernel@vger.kernel.org, Jack Steiner Subject: Re: init's children list is long and slows reaping children. References: <20070405195118.GH22762@lnx-holt.americas.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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