Balbir Singh wrote:
On Fri, Jun 5, 2009 at 11:33 AM, Avi Kivity <a...@redhat.com> wrote:
Bharata B Rao wrote:
Another way is to place the 8 groups in a container group, and limit
 that to 80%. But that doesn't work if I want to provide guarantees to
 several groups.

Hmm why not ? Reduce the guarantee of the container group and provide
the same to additional groups ?

This method produces suboptimal results:

$ cgroup-limits 10 10 0
[50.0, 50.0, 40.0]

I want to provide two 10% guaranteed groups and one best-effort group.
 Using the limits method, no group can now use more than 50% of the
resources.  However, having the first group use 90% of the resources does
not violate any guarantees, but it not allowed by the solution.


How, it works out fine in my calculation

50 + 40 for G2 and G3, make sure that G1 gets 10%, since others are
limited to 90%
50 + 40 for G1 and G3, make sure that G2 gets 10%, since others are
limited to 90%
50 + 50 for G1 and G2, make sure that G3 gets 0%, since others are
limited to 100%

It's fine in that it satisfies the guarantees, but it is deeply suboptimal. If I ran a cpu hog in the first group, while the other two were idle, it would be limited to 50% cpu. On the other hand, if it consumed all 100% cpu it would still satisfy the guarantees (as the other groups are idle).

The result is that in such a situation, wall clock time would double even though cpu resources are available.
Now if we really have zeros, I would recommend using

cgroup-limits 10 10 and you'll see that you'll get 90, 90 as output.

Adding zeros to the calcuation is not recommended. Does that help?

What do you mean, it is not recommended? I have two groups which need at least 10% and one which does not need any guarantee, how do I express it?

In any case, changing the zero to 1% does not materially change the results.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to