During our testing, we found that the cpu.shares doesn't work as
expected, the testing is:
X86 HOST:
12 CPU
GUEST(KVM):
6 VCPU
We create 3 GUEST, each with 1024 shares, the workload inside them is:
GUEST_1:
dbench 6
GUEST_2:
stress -c 6
GUEST_3:
stress -c 6
So by theory, each GUEST will got (1024 / (3 * 1024)) * 1200% == 400%
according to the group share (3 groups are created by virtual manager on
same level, and they are the only groups heavily running in system).
Now if only GUEST_1 running, it got 300% CPU, which is 1/4 of the whole
CPU resource.
So when all 3 GUEST running concurrently, we expect:
GUEST_1 GUEST_2 GUEST_3
CPU% 300% 450% 450%
That is the GUEST_1 got the 300% it required, and the unused 100% was
shared by the rest group.
But the result is:
GUEST_1 GUEST_2 GUEST_3
CPU% 40% 580% 580%
GUEST_1 failed to gain the CPU it required, and the dbench inside it
dropped a lot on performance.
So is this results expected (I really do not think so...)?
Or that imply the cpu-cgroup got some issue to be fixed?
Any comments are welcomed :)
Regards,
Michael Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
