mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: bharata@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: Fri, 5 Jun 2009 17:39:47 +0800	[thread overview]
Message-ID: <20090605093947.GJ11755@balbir.in.ibm.com> (raw)
In-Reply-To: <4A28B4CE.4010004@redhat.com>

* Avi Kivity <avi@redhat.com> [2009-06-05 09:01:50]:

> Bharata B Rao wrote:
>> On Fri, Jun 05, 2009 at 01:27:55PM +0800, Balbir Singh wrote:
>>   
>>> * Avi Kivity <avi@redhat.com> [2009-06-05 08:21:43]:
>>>
>>>     
>>>> Balbir Singh wrote:
>>>>       
>>>>>> But then there is no other way to make a *guarantee*, guarantees come
>>>>>> at a cost of idling resources, no? Can you show me any other
>>>>>> combination that will provide the guarantee and without idling the
>>>>>> system for the specified guarantees?
>>>>>>               
>>>>> OK, I see part of your concern, but I think we could do some
>>>>> optimizations during design. For example if all groups have reached
>>>>> their hard-limit and the system is idle, should we do start a new hard
>>>>> limit interval and restart, so that idleness can be removed. Would
>>>>> that be an acceptable design point?
>>>>>         
>>>> I think so.  Given guarantees G1..Gn (0 <= Gi <= 1; sum(Gi) <= 1), 
>>>> and a  cpu hog running in each group, how would the algorithm 
>>>> divide resources?
>>>>
>>>>       
>>> As per the matrix calculation, but as soon as we reach an idle point,
>>> we redistribute the b/w and start a new quantum so to speak, where all
>>> groups are charged up to their hard limits.
>>>     
>>
>> 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.

Yes, this feature needs to be configurable. But your use case for both
limits and guarantees is interesting. We spoke to Peter and he was
convinced only of the guarantee use case. Could you please help
elaborate your use case, so that we can incorporate it into RFC v2 we
send out. Peter is opposed to having hard limits and is convinced that
they are not generally useful, so far I seen you and Paul say it is
useful, any arguments you have or any +1 from you will help us. Peter
I am not back stabbing you :)


>
> 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).

Even limits are useful for SLA's since your b/w available changes
quite drastically as we add or remove groups. There are other use
cases for limits as well.


-- 
	Balbir

  parent reply	other threads:[~2009-06-05  9:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-04  5:36 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
2009-06-05  9:39                       ` Balbir Singh [this message]
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=20090605093947.GJ11755@balbir.in.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=avi@redhat.com \
    --cc=bharata@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

all inboxes | Powered by JetHome®