[Qemu-devel] KVM call minutes for Nov 30

[Qemu-devel] KVM call minutes for Nov 30

[Chris Wright]

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
- run Anthony's test load and discuss on list

[Qemu-devel] Re: KVM call minutes for Nov 30

[Anthony Liguori]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>