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.
Even limits are useful for SLA's since your b/w available changesSLAs are specified in terms of guarantees on a service, not on limits on
quite drastically as we add or remove groups. There are other use
cases for limits as well
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.