Re: KVM call minutes for Nov 30

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux