[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression thre
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads |
Date: |
Mon, 24 Nov 2014 10:16:19 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
On 11/23/2014 07:25 PM, Li, Liang Z wrote:
>>> # @auto-converge: If enabled, QEMU will automatically throttle down the
>>> guest
>>> # to speed up convergence of RAM migration. (since 1.6)
>>> #
>>> # Since: 1.2
>>> ##
>>> { 'enum': 'MigrationCapability',
>>> - 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks']
>>> }
>>> + 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>>> + 'compress'] }
>>>
>
>> I'll repeat what I said on v1 (but this time, with some links to back it up
>> :)
>
>> We really need to avoid a proliferation of new commands, two per tunable
>> does not scale well. I think now is the time to implement my earlier
>> suggestion at making MigrationCapability become THE resource for > tunables:
[please configure your mailer to wrap long lines]
>
>> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html
>
> Hi, Eric
>
> I have read your proposal, and I just want to verify if I got it
> exactly. Take the 'compresss-level' parameter for example, according to you
> suggestion, should I implement a command 'set-migrate-capability
> compress-level 1', or 'set-migrate-parameter compress-level 1' ? if it's
> the former, how to keep the HMP back compatibility, as you know, the current
> HMP framework will check the parameter type, the 'int' will be processed
> differently from 'bool', ; if it's the latter, it seems like a '
> query-migrate-paramer ' command should be provided to keep consistency, not
> query-migrate-capability.
HMP back-compat is NOT a problem we need to worry about; it's okay to
break the semantics if something else is easier to represent; it is only
QMP where we have to remain backwards compatible. We already have
set-migrate-capability, so that seems like the command to extend,
instead of adding a new one. On the other hand, if it is easier for you
to add a new HMP command that maps correctly to the underlying QMP
command, then that is fine, too. The point of my proposal is that the
QMP command can use a union to provide the correct typing as needed,
without worrying about what HMP has to do to match that.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH v2 0/2] migration: Add a new feature to do live migration, Li Liang, 2014/11/06
- [Qemu-devel] [v2 1/2] docs: Add a doc about multiple compression threads, Li Liang, 2014/11/06
- [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, Li Liang, 2014/11/06
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, Dr. David Alan Gilbert, 2014/11/06
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, ChenLiang, 2014/11/21
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, Li, Liang Z, 2014/11/21
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, ChenLiang, 2014/11/21
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, Li, Liang Z, 2014/11/21
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, ChenLiang, 2014/11/21
- Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads, ChenLiang, 2014/11/21