qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] migration: Improve QMP documentation


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] migration: Improve QMP documentation
Date: Fri, 22 Feb 2013 17:40:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Markus Armbruster <address@hidden> wrote:
> Juan Quintela <address@hidden> writes:
>
>>> I'm confused.  Do you mean pages that are entirely filled with the same
>>> byte?  Or pages with contents identical to some other, non-duplicate
>>> page?
>>
>> It is a page full of zeros.  Yes, we can have pages full of any other
>> char, they just haven't happened on my testing ever.
>>
>>> Sure we want to promise these are sent as a single byte?
>>
>> It is a binary format, we need to be incompatible to do it.
>
> "duplicate" is a badly misleading name.  I'm not asking you to change it
> in this patch.

name is older than my involvement with migration.  And it is externally
visible, so we can't change them.

> What about:
>
>          - "duplicate": number of pages filled entirely with the same
>            byte (json-int)
>            These are sent over the wire much more efficiently.

ok.  Changing to it.

>>>> +         - "normal" : number of whole pages transfered.  I.e. they
>>>> +            were not sent as duplicate or xbzrle pages (json-int)
>>>> +         - "normal-bytes" : number of bytes transferred in whole
>>>> +            pages. This is just normal pages times size of one page,
>>>> +            but this way upper levels don't need to care about page
>>>> +            size (json-int)
>>>
>>> Begs the question who wants "normal" then.
>>
>> Normal: we sent the whole page. 4096 bytes load on x86 (and almost
>> everything else).  "full" would be a better name.
>
> I'm afraid I was too terse, let me retry.  If "upper levels" want the
> amount of memory sent as whole pages as number of bytes
> ("normal-bytes"), who wants the same information as number of pages
> ("normal")?

we can't remove values.  And we have to say the amount on bytes because
we don't export anywhere what is the guest page_size.  Otherwise libvirt
would need to make tricks.  If I would be designing this today, I would
just add a field:

page_size: in bytes

And just sent everything else in pages.  Middleware can do any
calculation that they want then.

>
> I guess the answer is "no idea, I'm just trying to make the docs suck
> less."  And that's fair.

As said, historical reasons.

>>> Why don't "upper levels" want duplicate-bytes, too?
>>
>> duplicate-bytes == dupplicate, by definition.  for each duplicate page,
>> we just sent one byte.
>
> Retry: if "upper levels" want the amount of memory sent as whole pages
> as number of bytes rather than as number of pages, why are they happy to
> get the amount of memory sent more efficiently as "duplicates" in number
> of pages rather than number of bytes?

As said, upper levels don't know the page size.
And for the case of duplicate'd pages, we sent "one byte" for each page,
so "duplicate" and "duplicate-bytes" would be exactly the same number.

I know that you like this "optimization" O:-)

>>> A page is either sent normally (and counted in "normal"), or as
>>> duplicate (and counted in "duplicate"), or XBZRLE compressed.  Correct?
>>
>> Yeap.
>
> Thanks!

Thanks for the review.



reply via email to

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