On Tue, Sep 27, 2016 at 10:48:48AM +0100, Daniel P. Berrange wrote: > On Mon, Aug 29, 2016 at 11:06:48AM -0400, Stefan Hajnoczi wrote: > > At KVM Forum an interesting idea was proposed to avoid > > bdrv_drain_all() during live migration. Mike Cui and Felipe Franciosi > > mentioned running at queue depth 1. It needs more thought to make it > > workable but I want to capture it here for discussion and to archive > > it. > > > > bdrv_drain_all() is synchronous and can cause VM downtime if I/O > > requests hang. We should find a better way of quiescing I/O that is > > not synchronous. Up until now I thought we should simply add a > > timeout to bdrv_drain_all() so it can at least fail (and live > > migration would fail) if I/O is stuck instead of hanging the VM. But > > the following approach is also interesting... > > How would you decide what an acceptable timeout is for the drain > operation ?
Same as most timeouts: an arbitrary number :(. > At what point does a stuck drain op cause the VM > to stall ? The drain call has acquired the QEMU global mutex. Any vmexit that requires taking the QEMU global mutex will hang that thread (i.e. vcpu thread). Stefan
Description: PGP signature