Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750824AbWIUAaN (ORCPT ); Wed, 20 Sep 2006 20:30:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750830AbWIUAaN (ORCPT ); Wed, 20 Sep 2006 20:30:13 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:40092 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S1750824AbWIUAaL (ORCPT ); Wed, 20 Sep 2006 20:30:11 -0400 Subject: Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction From: Chandra Seetharaman Reply-To: sekharan@us.ibm.com To: Paul Menage Cc: npiggin@suse.de, CKRM-Tech , linux-kernel , pj@sgi.com, Rohit Seth , devel@openvz.org, Christoph Lameter In-Reply-To: <6599ad830609201257m22605deei25ae6a0eadb6c516@mail.google.com> References: <1158718568.29000.44.camel@galaxy.corp.google.com> <1158777240.6536.89.camel@linuxchandra> <6599ad830609201143h19f6883wb388666e27913308@mail.google.com> <1158778496.6536.95.camel@linuxchandra> <6599ad830609201225k3d38afe2gea7adc2fa8067e0@mail.google.com> <1158780923.6536.110.camel@linuxchandra> <6599ad830609201257m22605deei25ae6a0eadb6c516@mail.google.com> Content-Type: text/plain Organization: IBM Date: Wed, 20 Sep 2006 17:30:07 -0700 Message-Id: <1158798607.6536.112.camel@linuxchandra> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1665 Lines: 44 On Wed, 2006-09-20 at 12:57 -0700, Paul Menage wrote: > On 9/20/06, Chandra Seetharaman wrote: > > > At its most crude, this could be something like: > > > > > > struct container { > > > #ifdef CONFIG_CPUSETS > > > struct cpuset cs; > > > #endif > > > #ifdef CONFIG_RES_GROUPS > > > struct resource_group rg; > > > #endif > > > }; > > > > Won't it restrict the user to choose one of these, and not both. > > Not necessarily - you could have both compiled in, and each would only > worry about the resource management that they cared about - e.g. you > could use the memory node isolation portion of cpusets (in conjunction > with fake numa nodes/zones) for memory containment, but give every > cpuset access to all CPUs and control CPU usage via the resource > groups CPU controller. > > The generic code would take care of details like container > creation/destruction (with appropriate callbacks into cpuset and/or > res_group code, tracking task membership of containers, etc. What I am wondering is that whether the tight coupling of rg and cpuset (into a container data structure) is ok. > > Paul -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sekharan@us.ibm.com | .......you may get it. ---------------------------------------------------------------------- - 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/