Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964801AbWBFUgi (ORCPT ); Mon, 6 Feb 2006 15:36:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964804AbWBFUgi (ORCPT ); Mon, 6 Feb 2006 15:36:38 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:31105 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S964801AbWBFUgh (ORCPT ); Mon, 6 Feb 2006 15:36:37 -0500 To: Pavel Machek Cc: Kirill Korotaev , Linus Torvalds , Hubertus Franke , Dave Hansen , Greg KH , Alan Cox , "Serge E. Hallyn" , Arjan van de Ven , Linux Kernel Mailing List , Cedric Le Goater Subject: Re: RFC [patch 13/34] PID Virtualization Define new task_pid api References: <20060117155600.GF20632@sergelap.austin.ibm.com> <1137513818.14135.23.camel@localhost.localdomain> <1137518714.5526.8.camel@localhost.localdomain> <20060118045518.GB7292@kroah.com> <1137601395.7850.9.camel@localhost.localdomain> <43D14578.6060801@watson.ibm.com> <43E21BD0.6000606@sw.ru> <20060206201521.GA2470@ucw.cz> From: ebiederm@xmission.com (Eric W. Biederman) Date: Mon, 06 Feb 2006 13:34:58 -0700 In-Reply-To: <20060206201521.GA2470@ucw.cz> (Pavel Machek's message of "Mon, 6 Feb 2006 20:15:21 +0000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1275 Lines: 36 Pavel Machek writes: > Hi! > >> There are two issues here. >> 1) Monitoring. (ps, top etc) >> 2) Control (kill). >> >> For monitoring you might need to patch ps/top a little but it is doable > without >> 2 pids. >> >> For kill it is extremely rude to kill processes inside of a nested pid space. >> There are other solutions to the problem. > > Can you elaborate? If I have 10 containers with 1000 processes each, > it would be nice to be able to run top then kill 40 top cpu hogs.... So I just posted my patches to lkml if you want to see the details. But the way I have implemented it each container has a pid in it's parent's pid namespace. That pid to top looks essentially a thread group leader, and top will tell you which container contains the cpu hogs. Currently from the outside your choice is to kill or not kill the entire container. Which let's you kill the cpu hogs. The control is not broken down so fine that it is easy to do something the sysadmin of the container should be doing. Eric - 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/