qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v14 03/13] Add XBZRLE documentation


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v14 03/13] Add XBZRLE documentation
Date: Tue, 03 Jul 2012 13:45:05 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/03/2012 07:52 AM, Orit Wasserman wrote:
> Signed-off-by: Orit Wasserman <address@hidden>
> ---
>  docs/xbzrle.txt |  133 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 133 insertions(+), 0 deletions(-)
>  create mode 100644 docs/xbzrle.txt

> +
> +Example
> +old buffer:
> +1000 zeros
> +05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 00 00 6b 00 6d
> +3072 zeros

That's only 4092 bytes, but a page is typically 4096.  I think you meant
3076 trailing zeros.

> +
> +new buffer:
> +1000 zeros
> +01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 67 00 69
> +3702 zeros

That's 4722 bytes; looks like a transposition error, and given the above
comment, I still think you want 3076 trailing zeros.

> +
> +encoded buffer:
> +
> +encoded length 29
> +e8 07 18 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 67 00 69 00 00
> +00 80 18

Looks better, but still not quite accurate.  Per the spec, you always
end on a nzrun, which means you should not have transmitted the last two
bytes (80 18 => 3072, which is the length of your trailing zrun).  I
also find it weak that your example never shows an unchanged byte on
anything other than 00; having at least one non-zero unchanged byte may
make it more obvious in the encoded example that it is the xor
difference that determines a zrun vs. nzrun, and not the old or new
buffer contents.

Also, reading that encoding says you have 1000 zrun, then 24 bytes of
nzrun starting with a leading 00, but based on your old and new buffer,
the only way to have a leading 00 in your nzrun is if you count a zrun
of 999 bytes.  Are you sure you didn't test with a buffer of 1001
leading zeros, then 20 bytes of interest, then 3073 trailing zeros?

Given your old and new buffer as-is, and my assumption that you are
compressing a page of exactly 4096 bytes (3076 trailing zeros after your
20-byte window of interesting data), I see at least the following four
valid encodings, listed in increasing difficulty of computation:

8-byte long at a time; all chunks that differ in at least one byte are
treated as at least 8 bytes of nzrun, transmit 27 bytes
e8 07 18 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 67 00 69 00
00 00 00

4 bytes at a time; all chunks that differ in at least one byte are
treated as at least 4 bytes of nzrun, transmit 23 bytes
e8 07 14 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 00 67 00 69

list every single zrun (except trailing), even if only one byte long,
transmit 24 bytes
e8 07 0f 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 02 01 67 01 01 69

avoid a 1-byte zrun, transmit 23 bytes
e8 07 0f 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 02 03 67 00 69

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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