On 11/30/2010 09:53 AM, Chris Wright wrote:
2011 KVM Conference
- together with LF event like LinuxCon Vancouver BC (Aug), KS Prague (Nov)
- wider audience
- include qemu (tcg)
- include libvirt
- include xen
0.14.0 release plan
- could push things out, mainly want to keep on track for
infrastructure changes (irc channel migration, git tree migration)
- savannah down
- git.qemu.org was mirror, will start pushing there
- when savannah is back up, will become mirror (so git users should
still work)
- plan on moving #qemu to OFTC
nested VMX
- no progress, future plans are unclear
qemu users forum in grenoble
- worth having someone there
- goal to get embedded forks to push changes back to qemu
migration with large memory
- switching to 50ms cap likely to cause regression in terms of vcpu runtime
- 50ms qemu mutex contention, brief period of mutex access
- this has the effect of speeding up migration but giving too little vcpu
access to qemu mutex (network connections could terminate, for example)
- only fixes to this are to use bw limit or not holding qemu mutex during
mirgration
Right, to restate this, for some workloads, a VCPU needs to access
qemu_mutex potentially for the majority of it's execution. If we're
letting migration hold the mutex for 95% of the time even if we spread
the remaining 5% out for every 50ms, while we avoid having large
"stalls", it's only superficial. We're still breaking the migration
downtime contract.
The only solution is to limit the time migration is allowed to run which
is effectively what bandwidth limiting does. I'd be willing to
entertain a bandwidth limit expressed in terms of % CPU although I think
that's going to be a lot harder to compute than the current bandwidth limit.
And while setting a migration limit does increase migration, it's the
only solution that preserves fairness unless we stick migration into a
separate thread.
Regards,
Anthony Liguori
- run Anthony's test load and discuss on list
--
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
--
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
