Re: [Qemu-devel] [PATCH V5 5/9] migration: introduce postcopy-blocktime capability

[Alexey]

On Mon, May 22, 2017 at 11:20:13AM -0500, Eric Blake wrote:
> On 05/12/2017 08:31 AM, Alexey Perevalov wrote:
> > Right now it could be used on destination side to
> > enable vCPU blocktime calculation for postcopy live migration.
> > vCPU blocktime - it's time since vCPU thread was put into
> > interruptible sleep, till memory page was copied and thread awake.
> > 
> > Signed-off-by: Alexey Perevalov <address@hidden>
> > ---
> >  include/migration/migration.h | 1 +
> >  migration/migration.c         | 9 +++++++++
> >  qapi-schema.json              | 5 ++++-
> >  3 files changed, 14 insertions(+), 1 deletion(-)
> > 
> 
> > +++ b/qapi-schema.json
> > @@ -894,11 +894,14 @@
> >  # @release-ram: if enabled, qemu will free the migrated ram pages on the 
> > source
> >  #        during postcopy-ram migration. (since 2.9)
> >  #
> > +# @postcopy-blocktime: Calculate downtime for postcopy live migration 
> > (since 2.10)
> > +#
> >  # Since: 1.2
> >  ##
> >  { 'enum': 'MigrationCapability',
> >    'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> > -           'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram'] }
> > +           'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
> > +           'postcopy-blocktime'] }
> 
> Why does this need to be a capability that we have to turn on, and not
> something that is collected unconditionally? Is there a drawback to
> having the stat collection always enabled without a capability?
yes, it has a performance penalty
(runtime complexity O(n) + O(m), where n is vCPU number, m is number of memory
pages), but not so huge, compared to network
latencies, also memory usage, but no more than 0.03% of QEMU's total
memory.

> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 



-- 

BR
Alexey