From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:42700)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1Ri6kI-0003Mu-DH
	for qemu-devel@nongnu.org; Tue, 03 Jan 2012 10:57:51 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1Ri6kH-00028J-Gv
	for qemu-devel@nongnu.org; Tue, 03 Jan 2012 10:57:50 -0500
Received: from mx1.redhat.com ([209.132.183.28]:60848)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <owasserm@redhat.com>) id 1Ri6kH-000282-AI
	for qemu-devel@nongnu.org; Tue, 03 Jan 2012 10:57:49 -0500
Message-ID: <4F03254E.5020204@redhat.com>
Date: Tue, 03 Jan 2012 17:57:02 +0200
From: Orit Wasserman <owasserm@redhat.com>
MIME-Version: 1.0
References: <1325604879-15862-1-git-send-email-owasserm@redhat.com>
	<1325604879-15862-9-git-send-email-owasserm@redhat.com>
	<CAJSP0QUtOidhXSZvGB2noAqOqoRObgDU6U+brrrz5_-ncmWoxw@mail.gmail.com>
In-Reply-To: <CAJSP0QUtOidhXSZvGB2noAqOqoRObgDU6U+brrrz5_-ncmWoxw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v5 8/9] QMP commands changes
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org, quintela@redhat.com

On 01/03/2012 05:47 PM, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 3:34 PM, Orit Wasserman <owasserm@redhat.com> wrote:
>> +        .args_type  = "detach:-d,blk:-b,inc:-i,xbrle:-x,uri:s",
>> +        .params     = "[-d] [-b] [-i] [-x] uri",
>> +        .help       = "migrate to URI"
>> +                      "\n\t -d to not wait for completion"
>> +                      "\n\t -b for migration without shared storage with"
>> +                      " full copy of disk"
>> +                      "\n\t -i for migration without"
>> +                      " shared storage with incremental copy of disk"
>> +                      " (base image shared between source and destination)"
>> +                      "\n\t -x to use XBRLE page delta compression",
> 
> It's too bad that this algorithm is user-visible and needs to be
> expicitly enabled/disabled.  I think it would be useful in a much
> wider range of cases if the trade-offs were understood well enough so
> that QEMU can include a threshold or heuristic which chooses the
> migration algorithm behind the scenes.

I agree that an automatic switching on/off XBRLE is very desirable. 
At the first phase we merge it as a user option, and the in the next phase will be adding
the part that switch it on/off.
> 
> I'm afraid that locking XBRLE behind an explicit option means we're
> merging dead code.  What do you think?

Even as a user option this option will be useful , in many cases users are aware of 
their workload and can set this option on.

Orit
> 
> Stefan