public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
	Gautham R Shenoy <ego@in.ibm.com>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Pavel Emelyanov <xemul@openvz.org>,
	kvm@vger.kernel.org,
	Linux Containers <containers@lists.linux-foundation.org>,
	Herbert Poetzl <herbert@13thfloor.at>
Subject: Re: [RFC] CPU hard limits
Date: Sun, 7 Jun 2009 21:44:40 +0530	[thread overview]
Message-ID: <20090607161440.GA3609@in.ibm.com> (raw)
In-Reply-To: <4A2B5881.9060204@redhat.com>

On Sun, Jun 07, 2009 at 09:04:49AM +0300, Avi Kivity wrote:
> 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?

I was saying that we specify only limits and not guarantees since it
can be worked out from limits. Initial thinking was that the kernel will
be made aware of only limits and users could set the limits appropriately
to obtain the desired guarantees. I understand your concerns/objections
on this and we will address this in our next version of RFC as Balbir said.

Regards,
Bharata.

  reply	other threads:[~2009-06-07 16:15 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-04  5:36 [RFC] CPU hard limits Bharata B Rao
2009-06-04 12:19 ` Avi Kivity
2009-06-04 21:32   ` Mike Waychison
2009-06-05  3:03   ` Bharata B Rao
2009-06-05  3:33     ` Avi Kivity
2009-06-05  4:37       ` Balbir Singh
2009-06-05  4:44         ` Avi Kivity
2009-06-05  4:49           ` Balbir Singh
2009-06-05  5:09             ` Chris Friesen
2009-06-05  5:13               ` Balbir Singh
2009-06-05  5:10             ` Balbir Singh
2009-06-05  5:21               ` Avi Kivity
2009-06-05  5:27                 ` Balbir Singh
2009-06-05  5:31                   ` Bharata B Rao
2009-06-05  6:01                     ` Avi Kivity
2009-06-05  8:16                       ` Bharata B Rao
2009-06-07  6:04                         ` Avi Kivity
2009-06-07 16:14                           ` Bharata B Rao [this message]
2009-06-05  9:39                       ` Balbir Singh
2009-06-05 13:14                         ` Avi Kivity
2009-06-05 13:42                           ` Balbir Singh
2009-06-07  6:09                             ` Avi Kivity
2009-06-05 14:54                           ` Chris Friesen
2009-06-07  6:10                             ` Avi Kivity
2009-06-05  9:24                     ` Balbir Singh
2009-06-05  6:03                   ` Avi Kivity
2009-06-05  6:32                     ` Bharata B Rao
2009-06-05 12:57                       ` Avi Kivity
2009-06-05  5:16             ` Avi Kivity
2009-06-05  5:20               ` Balbir Singh
2009-06-05  3:07   ` Balbir Singh
2009-06-05  8:53 ` Paul Menage
2009-06-05  9:27   ` Bharata B Rao
2009-06-05  9:32     ` Paul Menage
2009-06-05  9:48       ` Dhaval Giani
2009-06-05  9:51         ` Paul Menage
2009-06-05  9:59           ` Dhaval Giani
2009-06-05 10:03             ` Paul Menage
2009-06-08  8:50               ` Pavel Emelyanov
2009-06-05  9:36   ` Balbir Singh
2009-06-05  9:48     ` Paul Menage
2009-06-05  9:55       ` Balbir Singh
2009-06-05  9:57         ` Paul Menage
2009-06-05 10:02         ` Paul Menage
2009-06-05 11:32   ` Srivatsa Vaddagiri
2009-06-05 12:18     ` Paul Menage
2009-06-07 10:11       ` Srivatsa Vaddagiri
2009-06-07 15:35         ` Balbir Singh
2009-06-08  4:37           ` Srivatsa Vaddagiri
2009-06-05 14:44     ` Chris Friesen
2009-06-05 13:02   ` Avi Kivity
2009-06-05 13:43     ` Dhaval Giani
2009-06-05 14:45       ` Chris Friesen
2009-06-05  9:02 ` Reinhard Tartler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090607161440.GA3609@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=avi@redhat.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=vatsa@in.ibm.com \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox