Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755029AbZFEJ6A (ORCPT ); Fri, 5 Jun 2009 05:58:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751433AbZFEJ5x (ORCPT ); Fri, 5 Jun 2009 05:57:53 -0400 Received: from smtp-out.google.com ([216.239.45.13]:14608 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbZFEJ5w (ORCPT ); Fri, 5 Jun 2009 05:57:52 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=TMaMgQuMO+pli7ZmSkehj0altdTcX3ey6lCfy+z6BWj2GtnDJmPvAtPiferUmS3Kf PpWuaM+6YugkatYGyi+AQ== MIME-Version: 1.0 In-Reply-To: <20090605095527.GM11755@balbir.in.ibm.com> References: <20090604053649.GA3701@in.ibm.com> <6599ad830906050153i1afd104fqe70f681317349142@mail.gmail.com> <20090605093625.GI11755@balbir.in.ibm.com> <6599ad830906050248m2c569e5bx44fb3bbddf46f8b1@mail.gmail.com> <20090605095527.GM11755@balbir.in.ibm.com> Date: Fri, 5 Jun 2009 02:57:50 -0700 Message-ID: <6599ad830906050257q60e124dbt20dea7c6065f1edc@mail.gmail.com> Subject: Re: [RFC] CPU hard limits From: Paul Menage To: balbir@linux.vnet.ibm.com Cc: bharata@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, Dhaval Giani , Vaidyanathan Srinivasan , Gautham R Shenoy , Srivatsa Vaddagiri , Ingo Molnar , Peter Zijlstra , Pavel Emelyanov , Avi Kivity , kvm@vger.kernel.org, Linux Containers , Herbert Poetzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 839 Lines: 17 On Fri, Jun 5, 2009 at 2:55 AM, Balbir Singh wrote: > The point is that there is no single control entity for creating > groups. if run a solution, it might create groups without telling the > user. No one is arbitrating, not even libcgroup. What if someone > changes the cpuset assignment and moves CPUS x to y in an exclusive > cpuset all of a sudden. How do we arbitrate? But in that situation, how do hard limits help? If you can't control when cgroups are being created, and you can't control their shares, how are you going to control their hard limits? Paul -- 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/