On Fri, Jun 5, 2009 at 6:44 PM, Avi Kivity<avi@xxxxxxxxxx> wrote: > Balbir Singh wrote: >>> >>> 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 am selling virtual private servers. A 10% cpu share costs $x/month, and I > guarantee you'll get that 10%, or your money back. On the other hand, I > want to limit cpu usage to that 10% (maybe a little more) so people don't > buy 10% shares and use 100% on my underutilized servers. If they want 100%, > let them pay for 100%. Excellent examples, we've covered them in the RFC, could you see if we missed anything in terms of use cases? The real question is do we care enough to build hard limits control into the CFS group scheduler. I believe we should. > >>> 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 > > SLAs are specified in terms of guarantees on a service, not on limits on > others. If we could use limits to provide guarantees, that would be fine, > but it doesn't quite work out. To be honest, I would disagree here, specifically if you start comparing how you would build guarantees in the kernel and compare it with the proposed approach. I don't want to harp on the technicality, but point out the feasibility for people who care for lower end of the guarantee without requiring density. I think the real technical discussion should be on here are the use cases, lets agree on the need for the feature and go ahead and start prototyping the feature. Thanks, Balbir -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
