Balbir Singh wrote:
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.
You only cover the limit part. Guarantees are left as an exercise to
the reader.
I don't think implementing guarantees via limits is workable as it
causes the cpu to be idled unnecessarily.
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.
I don't understand. Are you saying implementing guarantees is too complex?
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
