alex wrote:
just now, I tried cgroup. I admit that as far as only CPU share is
concerned, cgroup is enough.
However, AFAIK Linux schedules each thread independently, ignoring the
upper level logic.
for example, suppose VM1 is an SMP one, and it is used to receive
network packets, which causes it run the TCP/IP stack code frequently.
The use of spin-lock implies that the lock holder will release it
fast. However, when vcpu threads are scheduled independently, when one
vcpu is spinning, the lock holder might be off the CPU! This would
make the VM's SMP scalability bad.
Sure, but credit doesn't do gang scheduling either.
Instead of gang scheduling, I think the best solution to this problem is
spin lock paravirtualization.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
