On 19/11/10 00:11, Kenni Lund wrote:
I think cgroups is the solution, if you want to guarantee resources to some guests. I haven't tested it with KVM, but perhaps "nice" and "ionice" can be useful as well...the guests are just Linux processes after all.
Just to clarify, it isn't that *I* want to guarantee equal time sharing, it's that the entire premise of co-scheduling implies that the guest VM's OS may malfunction if the system doesn't guarantee it, or some approximation of it.
To quote from http://communities.vmware.com/docs/DOC-4960:
Without coscheduling, the VCPUs associated with an SMP VM would be scheduled independently, breaking the guest's assumptions regarding uniform progress. We use the term "skew" to refer to the difference in execution rates between two or more VCPUs associated with an SMP VM.
Inter-VCPU skew violates the assumptions of guest software. Non-trivial skew can result in severe performance problems, and may even induce failures when the guest expects inter-VCPU operations to complete quickly. Let's first consider the performance implications of skew. Guest OS kernels typically use spin locks for interprocessor synchronization. If the VCPU currently holding a lock is descheduled, then the other VCPUs in the same VM will waste time busy-waiting until the lock is released. Similar performance problems can also occur in multi-threaded user-mode applications, which may also synchronize using locks or barriers. Unequal VCPU progress will also confuse the guest OS cpu scheduler, which attempts to balance load across VCPUs.
N