From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751231AbWFBIoL (ORCPT ); Fri, 2 Jun 2006 04:44:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751334AbWFBIoL (ORCPT ); Fri, 2 Jun 2006 04:44:11 -0400 Received: from mail.gmx.de ([213.165.64.20]:9109 "HELO mail.gmx.net") by vger.kernel.org with SMTP id S1751231AbWFBIoJ (ORCPT ); Fri, 2 Jun 2006 04:44:09 -0400 X-Authenticated: #14349625 Subject: Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps From: Mike Galbraith To: Peter Williams Cc: sekharan@us.ibm.com, balbir@in.ibm.com, dev@openvz.org, Andrew Morton , Srivatsa , Sam Vilain , ckrm-tech@lists.sourceforge.net, Balbir Singh , Con Kolivas , Linux Kernel , Kingsley Cheung , "Eric W. Biederman" , Ingo Molnar , Rene Herman In-Reply-To: <447FD2E1.7060605@bigpond.net.au> References: <20060526042021.2886.4957.sendpatchset@heathwren.pw.nest> <20060526042051.2886.70594.sendpatchset@heathwren.pw.nest> <661de9470605262348s52401792x213f7143d16bada3@mail.gmail.com> <44781167.6060700@bigpond.net.au> <447D95DE.1080903@sw.ru> <447DBD44.5040602@in.ibm.com> <447E9A1D.9040109@openvz.org> <447EA694.8060407@in.ibm.com> <1149187413.13336.24.camel@linuxchandra> <447FD2E1.7060605@bigpond.net.au> Content-Type: text/plain Date: Fri, 02 Jun 2006 10:46:32 +0200 Message-Id: <1149237992.9446.133.camel@Homer.TheSimpsons.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2006-06-02 at 15:55 +1000, Peter Williams wrote: > Chandra Seetharaman wrote: > > On Thu, 2006-06-01 at 14:04 +0530, Balbir Singh wrote: > >> Hi, Kirill, > >> > >> Kirill Korotaev wrote: > >>>> Do you have any documented requirements for container resource > >>>> management? > >>>> Is there a minimum list of features and nice to have features for > >>>> containers > >>>> as far as resource management is concerned? > >>> Sure! You can check OpenVZ project (http://openvz.org) for example of > >>> required resource management. BTW, I must agree with other people here > >>> who noticed that per-process resource management is really useless and > >>> hard to use :( > > > > I totally agree. > > "nice" seems to be doing quite nicely :-) > > To me this capping functionality is a similar functionality to that > provided by "nice" and all that's needed to make it useful is a command > (similar to "nice") that runs tasks with caps applied. Similar in that they are both inherited. Very dissimilar in that the effect of nice is not altered by fork whereas the effect of a cap is. Consider make. A cap on make itself isn't meaningful, and _any_ per task cap you put on it with the intent of managing the aggregate, is defeated by the argument -j. Per task caps require omniscience to be effective in managing processes. That's a pretty severe limitation. -Mike