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