[PULL,00/34] migration thread and queue

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).

>> 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

Paolo Bonzini <pbonzini@redhat.com> wrote:
> 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).
>
>>> 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.

I didn't included them jsut to do the pull request with the patches
already reviewed, was going to add them to next pull request (patches
are "trivial" right).  famous last words.

Just including patches in a pull request not before is something Anthony
don't like.

Later, Juan.

Paolo Bonzini <pbonzini@redhat.com> 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

Il 21/12/2012 14:39, Anthony Liguori ha scritto:
> Do you think this would cause the behavior I've seen?  Not clear to me.

No idea, the first two hunks however are locking fixes, who knows what
they might cause.

Paolo