[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 06/12] migration: do not detect zero page for co
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 06/12] migration: do not detect zero page for compression |
Date: |
Fri, 29 Jun 2018 10:42:14 +0100 |
User-agent: |
Mutt/1.10.0 (2018-05-17) |
* Xiao Guangrong (address@hidden) wrote:
>
> Hi Peter,
>
> Sorry for the delay as i was busy on other things.
>
> On 06/19/2018 03:30 PM, Peter Xu wrote:
> > On Mon, Jun 04, 2018 at 05:55:14PM +0800, address@hidden wrote:
> > > From: Xiao Guangrong <address@hidden>
> > >
> > > Detecting zero page is not a light work, we can disable it
> > > for compression that can handle all zero data very well
> >
> > Is there any number shows how the compression algo performs better
> > than the zero-detect algo? Asked since AFAIU buffer_is_zero() might
> > be fast, depending on how init_accel() is done in util/bufferiszero.c.
>
> This is the comparison between zero-detection and compression (the target
> buffer is all zero bit):
>
> Zero 810 ns Compression: 26905 ns.
> Zero 417 ns Compression: 8022 ns.
> Zero 408 ns Compression: 7189 ns.
> Zero 400 ns Compression: 7255 ns.
> Zero 412 ns Compression: 7016 ns.
> Zero 411 ns Compression: 7035 ns.
> Zero 413 ns Compression: 6994 ns.
> Zero 399 ns Compression: 7024 ns.
> Zero 416 ns Compression: 7053 ns.
> Zero 405 ns Compression: 7041 ns.
>
> Indeed, zero-detection is faster than compression.
>
> However during our profiling for the live_migration thread (after reverted
> this patch),
> we noticed zero-detection cost lots of CPU:
>
> 12.01% kqemu qemu-system-x86_64 [.] buffer_zero_sse2
>
>
> ◆
Interesting; what host are you running on?
Some hosts have support for the faster buffer_zero_ss4/avx2
> 7.60% kqemu qemu-system-x86_64 [.] ram_bytes_total
>
>
> ▒
> 6.56% kqemu qemu-system-x86_64 [.] qemu_event_set
>
>
> ▒
> 5.61% kqemu qemu-system-x86_64 [.] qemu_put_qemu_file
>
>
> ▒
> 5.00% kqemu qemu-system-x86_64 [.] __ring_put
>
>
> ▒
> 4.89% kqemu [kernel.kallsyms] [k]
> copy_user_enhanced_fast_string
>
> ▒
> 4.71% kqemu qemu-system-x86_64 [.] compress_thread_data_done
>
>
> ▒
> 3.63% kqemu qemu-system-x86_64 [.] ring_is_full
>
>
> ▒
> 2.89% kqemu qemu-system-x86_64 [.] __ring_is_full
>
>
> ▒
> 2.68% kqemu qemu-system-x86_64 [.]
> threads_submit_request_prepare
>
> ▒
> 2.60% kqemu qemu-system-x86_64 [.] ring_mp_get
>
>
> ▒
> 2.25% kqemu qemu-system-x86_64 [.] ring_get
>
>
> ▒
> 1.96% kqemu libc-2.12.so [.] memcpy
>
> After this patch, the workload is moved to the worker thread, is it
> acceptable?
>
> >
> > From compression rate POV of course zero page algo wins since it
> > contains no data (but only a flag).
> >
>
> Yes it is. The compressed zero page is 45 bytes that is small enough i think.
So the compression is ~20x slow and 10x the size; not a great
improvement!
However, the tricky thing is that in the case of a guest which is mostly
non-zero, this patch would save that time used by zero detection, so it
would be faster.
> Hmm, if you do not like, how about move detecting zero page to the work
> thread?
That would be interesting to try.
Dave
> Thanks!
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [PATCH 05/12] migration: show the statistics of compression, (continued)
[Qemu-devel] [PATCH 07/12] migration: hold the lock only if it is really needed, guangrong . xiao, 2018/06/04
[Qemu-devel] [PATCH 08/12] migration: do not flush_compressed_data at the end of each iteration, guangrong . xiao, 2018/06/04
[Qemu-devel] [PATCH 09/12] ring: introduce lockless ring buffer, guangrong . xiao, 2018/06/04