qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 8/9] QMP commands changes


From: Orit Wasserman
Subject: Re: [Qemu-devel] [PATCH v5 8/9] QMP commands changes
Date: Tue, 03 Jan 2012 17:57:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 01/03/2012 05:47 PM, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 3:34 PM, Orit Wasserman <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]