qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Liang Li <liang.z.li@intel.com>,
	qemu-devel@nongnu.org, amit.shah@redhat.com
Subject: Re: [Qemu-devel] [PATCH] migration: Fix multi-thread compression bug
Date: Wed, 04 May 2016 11:03:21 +0200	[thread overview]
Message-ID: <87d1p2urdy.fsf@emacs.mitica> (raw)
In-Reply-To: <20160503163908.GJ2242@work-vm> (David Alan Gilbert's message of "Tue, 3 May 2016 17:39:09 +0100")

"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Liang Li (liang.z.li@intel.com) wrote:
>> Recently, a bug related to multiple thread compression feature for
>> live migration is reported. The destination side will be blocked
>> during live migration if there are heavy workload in host and
>> memory intensive workload in guest, this is most likely to happen
>> when there is one decompression thread.
>> 
>> Some parts of the decompression code are incorrect:
>> 1. The main thread receives data from source side will enter a busy
>> loop to wait for a free decompression thread.
>> 2. A lock is needed to protect the decomp_param[idx]->start, because
>> it is checked in the main thread and is updated in the decompression
>> thread.
>> 
>> Fix these two issues by following the code pattern for compression.
>> 
>
> OK, I think that's an improvement - but I have a question.
> Since it's an improvement (and basically now the same as compress):
>
> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>
> however, my question is:
> What guarantee's that all of the decompression has finished by the time
> the VM is started?  I see in migration/migration.c that we have:
>
>     if (!global_state_received() ||
>         global_state_get_runstate() == RUN_STATE_RUNNING) {
>         if (autostart) {
>             vm_start();
>         } else {
>             runstate_set(RUN_STATE_PAUSED);
>         }
>     } else {
>         runstate_set(global_state_get_runstate());
>     }
>     migrate_decompress_threads_join();

You are right here.  If we don't want to do the join earlier, we need to
do the equivalent of looking that all threads have set param->done as true.
That is what I do on the multiple-fd code.

Later, Juan.

  parent reply	other threads:[~2016-05-04  9:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-03  6:38 [Qemu-devel] [PATCH] migration: Fix multi-thread compression bug Liang Li
2016-05-03  6:43 ` Li, Liang Z
2016-05-03 10:44 ` Daniel P. Berrange
2016-05-03 16:39 ` Dr. David Alan Gilbert
2016-05-04  1:10   ` Li, Liang Z
2016-05-04  9:03   ` Juan Quintela [this message]
2016-05-04  9:11 ` Juan Quintela
2016-05-04 10:03   ` Li, Liang Z

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1p2urdy.fsf@emacs.mitica \
    --to=quintela@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=liang.z.li@intel.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).