From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Waychison Subject: Re: [RFC] CPU hard limits Date: Thu, 04 Jun 2009 14:32:34 -0700 Message-ID: <4A283D72.6070603@google.com> References: <20090604053649.GA3701@in.ibm.com> <4A27BBCA.5020606@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bharata@linux.vnet.ibm.com, Peter Zijlstra , Pavel Emelyanov , Dhaval Giani , kvm@vger.kernel.org, Gautham R Shenoy , Linux Containers , linux-kernel@vger.kernel.org, Ingo Molnar , Balbir Singh To: Avi Kivity Return-path: Received: from smtp-out.google.com ([216.239.33.17]:3445 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754549AbZFDVcm (ORCPT ); Thu, 4 Jun 2009 17:32:42 -0400 In-Reply-To: <4A27BBCA.5020606@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Bharata B Rao wrote: >> 2. Need for hard limiting CPU resource >> -------------------------------------- >> - Pay-per-use: In enterprise systems that cater to multiple clients/customers >> where a customer demands a certain share of CPU resources and pays only >> that, CPU hard limits will be useful to hard limit the customer's job >> to consume only the specified amount of CPU resource. >> - In container based virtualization environments running multiple containers, >> hard limits will be useful to ensure a container doesn't exceed its >> CPU entitlement. >> - Hard limits can be used to provide guarantees. >> > How can hard limits provide guarantees? Hard limits are useful and desirable in situations where we would like to maintain deterministic behavior. Placing a hard cap on the cpu usage of a given task group (and configuring such that this cpu time is not overcommited) on a system allows us to create a hard guarantee that throughput for that task group will not fluctuate as other workloads are added and removed on the system. Cache use and bus bandwidth in a multi-workload environment can still cause a performance deviation, but these are second order compared to the cpu scheduling guarantees themselves. Mike Waychison