Re: [Qemu-devel] [PULL 00/34] migration thread and queue

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> Il 21/12/2012 02:39, Juan Quintela ha scritto:
>>> I can't bisect tonight but can attempt to tomorrow.  How has this been
>>> tested?
>> 
>> I have tested with tcp, load/not-load with guests form 4GB to 16GB RAM.
>> Will test tomorrow with your test case.  I didn't tested exec:, though.
>> 
>>>
>>> I'm a little concerned here about the timing.  With the Christmas
>>> and New Years holiday we're pretty darn close to soft freeze for 1.4.
>
> (To expand on my previous message, might as well declare soft freeze
> today if that is the case).

I think you misread my comment.  I'm not saying that I don't want to
take this series before soft freeze.  I'm reminding everyone that we're
getting close to soft freeze so we need to get this merged ASAP.

After the Christmas break, we'll have less than two weeks before soft
freeze.  That's not a tremendous amount of time to work out issues...

>
>>> Has this series gone through a full autotest run with multiple guests?
>> 
>> Will re-test tomorrow with autotest.
>
> You haven't integrated the fixes I sent you yesterday (attached and
> placed at migration-thread-20121220-lite).  I'm running autotest now.
>
> Paolo
> diff --git a/Makefile.objs b/Makefile.objs
> index 4ef0a71..971b2f5 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -78,7 +78,6 @@ extra-obj-$(CONFIG_LINUX) += fsdev/
>  
>  common-obj-y += tcg-runtime.o host-utils.o main-loop.o
>  common-obj-y += migration.o migration-tcp.o
> -common-obj-y += migration.o migration-tcp.o
>  common-obj-y += qemu-char.o #aio.o
>  common-obj-y += block-migration.o iohandler.o
>  common-obj-y += bitmap.o bitops.o
> diff --git a/arch_init.c b/arch_init.c
> index 86f8544..dada6de 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -642,12 +642,13 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
>          i++;
>      }
>  
> +    qemu_mutex_unlock_ramlist();
> +
>      if (ret < 0) {
>          bytes_transferred += total_sent;
>          return ret;
>      }
>  
> -    qemu_mutex_unlock_ramlist();
>      qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
>      total_sent += 8;
>      bytes_transferred += total_sent;
> @@ -657,9 +658,8 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
>  
>  static int ram_save_complete(QEMUFile *f, void *opaque)
>  {
> -    migration_bitmap_sync();
> -
>      qemu_mutex_lock_ramlist();
> +    migration_bitmap_sync();
>  
>      /* try transferring iterative blocks of memory */
>  
> diff --git a/migration.c b/migration.c
> index c69e864..ecda263 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -20,8 +20,8 @@
>  #include "sysemu/sysemu.h"
>  #include "block/block.h"
>  #include "qemu/sockets.h"
> -#include "migration/block.h"
>  #include "qemu/thread.h"
> +#include "migration/block.h"
>  #include "qmp-commands.h"
>  
>  //#define DEBUG_MIGRATION
> @@ -650,8 +650,8 @@ static int64_t buffered_set_rate_limit(void *opaque, 
> int64_t new_rate)
>          new_rate = SIZE_MAX;
>      }
>  
> -    s->xfer_limit = new_rate / 10;
> -
> +    s->xfer_limit = new_rate / XFER_LIMIT_RATIO;
> +    
>  out:
>      return s->xfer_limit;
>  }

Do you think this would cause the behavior I've seen?  Not clear to me.

Regards,

Anthony Liguori