From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] CPU hard limits Date: Sun, 07 Jun 2009 09:04:49 +0300 Message-ID: <4A2B5881.9060204@redhat.com> References: <20090605030309.GA3872@in.ibm.com> <4A28921C.6010802@redhat.com> <661de9470906042137u603e2997n80c270bf7f6191ad@mail.gmail.com> <4A28A2AB.3060108@redhat.com> <20090605044946.GA11755@balbir.in.ibm.com> <20090605051050.GB11755@balbir.in.ibm.com> <4A28AB67.7040800@redhat.com> <20090605052755.GE11755@balbir.in.ibm.com> <20090605053159.GB3872@in.ibm.com> <4A28B4CE.4010004@redhat.com> <20090605081651.GD3872@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Balbir Singh , linux-kernel@vger.kernel.org, Dhaval Giani , Vaidyanathan Srinivasan , Gautham R Shenoy , Srivatsa Vaddagiri , Ingo Molnar , Peter Zijlstra , Pavel Emelyanov , kvm@vger.kernel.org, Linux Containers , Herbert Poetzl To: bharata@linux.vnet.ibm.com Return-path: Received: from mx2.redhat.com ([66.187.237.31]:42293 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751993AbZFGGGr (ORCPT ); Sun, 7 Jun 2009 02:06:47 -0400 In-Reply-To: <20090605081651.GD3872@in.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Bharata B Rao wrote: > On Fri, Jun 05, 2009 at 09:01:50AM +0300, Avi Kivity wrote: > >> Bharata B Rao wrote: >> >>> But could there be client models where you are required to strictly >>> adhere to the limit within the bandwidth and not provide more (by advancing >>> the bandwidth period) in the presence of idle cycles ? >>> >>> >> That's the limit part. I'd like to be able to specify limits and >> guarantees on the same host and for the same groups; I don't think that >> works when you advance the bandwidth period. >> >> I think we need to treat guarantees as first-class goals, not something >> derived from limits (in fact I think guarantees are more useful as they >> can be used to provide SLAs). >> > > I agree that guarantees are important, but I am not sure about > > 1. specifying both limits and guarantees for groups and > Why would you allow specifying a lower bound for cpu usage (a guarantee), and upper bound (a limit), but not both? > 2. not deriving guarantees from limits. > > Guarantees are met by some form of throttling or limiting and hence I think > limiting should drive the guarantees That would be fine if it didn't idle the cpu despite there being demand and available cpu power. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.