[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] migration next tree
From: |
Orit Wasserman |
Subject: |
Re: [Qemu-devel] [RFC] migration next tree |
Date: |
Sun, 24 Jun 2012 09:30:55 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
On 06/22/2012 11:43 PM, Vinod Chegu wrote:
>
>
> On Fri, Jun 22, 2012 at 6:59 AM, Juan Quintela <address@hidden
> <mailto:address@hidden>> wrote:
>
>
> Hi
>
> As discussed on this week kvm call, here are the migration tree with
> XBRLE + huge memory fixes integrated. There were a bug on huge memory
> (corrected on the v3 version just sent) and another on XZBRLE patches.
> Orit is going to resend patches addressing comments, but here the fix is
> integrated already.
>
> How to test?
>
> Compile qemu with trace support:
>
> ./configure --enable-trace-backend=simple
>
> Create an event file:
>
> $ cat /tmp/events
> savevm_section_start
> savevm_section_end
> $
>
> Now launch qemu with normal command line:
>
> qemu ..... --trace events=/tmp/events
>
> And when execution finish, you can use a script like the following to
> see the stalls that happen:
>
> $ cat ~/counter_simpletrace
> $1 ~ /savevm_section_end/ {
> /* Print savevm_section_stop line when >100 ms duration */
> if ($2 > 50000) {
> printf("%s times_missing=%u\n", $0, times_missing++);
> }
> }
> $
>
> And now you can analize:
>
> ./scripts/simpletrace.py ./trace-events trace-32554 | awk -f
> ~/counter_simpletrace
>
> (adjust paths as required)
>
> Notice that this are stalls on the iothread. vcpus stalls can still be
> bigger. The number that is tested here is 50ms, so I get cases that are
> a bit bigger (between 60-100ms with one 8GB guest that is dirtying 512MB
> in a loop.
>
> If you get stalls, or drop connections, please let me know the load.
>
> Thanks, Juan.
>
>
> The following changes since commit
> 47ecbdf07ed2c37bdfd2d77137d01bb319ce13da:
>
> libcacard: build fixes (2012-06-21 20:04:24 +0000)
>
> are available in the git repository at:
>
> http://repo.or.cz/r/qemu/quintela.git migration-next
>
> for you to fetch changes up to 0844b46b5d7d8d6fa01134d170b3c48b7f32eab7:
>
> Add XBZRLE statistics (2012-06-22 15:24:15 +0200)
>
>
> Currently this XBZRLE related stats are only available during the active
> migration but not
> after the completion. Can we get this information even after the completion
> of the XBZRLE migration (via info migrate) ? It would help to keep track of
> the final list of cache misses/hits etc.
>
Sure , I will add it in the next patch set.
> To the generic migration statistics that gets displayed via "info migrate"
> can you pl. consider adding the duration of Stage3 (i.e. "Downtime") as
> measured on the source host (yes there is probably some time spent in the
> resuming of the guest on the destination host...).
>
> Ideally this "Downtime" should be the pretty close to the pre-defined
> downtime (i.e. default value(30ms?) or whatever the user set it to via
> migrate_set_downtime command). But it looks like on larger guests that is not
> the case...
>
> Still reviewing the code and testing it out...
>
> Thanks
> Vinod
>
>
>
>
> ----------------------------------------------------------------
> Isaku Yamahata (1):
> Add MigrationParams structure
>
> Juan Quintela (8):
> Add spent time for migration
> Add tracepoints for savevm section start/end
> No need to iterate if we already are over the limit
> Only TCG needs TLB handling
> Only calculate expected_time for stage 2
> Exit loop if we have been there too long
> dirty bitmap: abstract its use
> Maintain the number of dirty pages
>
> Orit Wasserman (13):
> Add missing check for host_from_stream_offset return value for
> RAM_SAVE_FLAG_PAGE
> Add migration capabilites
> Add XBZRLE documentation
> Add cache handling functions
> Add uleb encoding/decoding functions
> Add save_block_hdr function
> Add debugging infrastructure
> Change ram_save_block to return -1 if there are no more changes
> Add migration_end function
> Add xbzrle_encode_buffer and xbzrle_decode_buffer functions
> Add XBZRLE to ram_save_block and ram_save_live
> Add set_cachesize command
> Add XBZRLE statistics
>
> Makefile.objs | 1 +
> arch_init.c | 378
> ++++++++++++++++++++++++++++++++++++++++++++------
> block-migration.c | 8 +-
> cache.c | 219 +++++++++++++++++++++++++++++
> cpu-all.h | 1 +
> cutils.c | 29 ++++
> docs/xbzrle.txt | 115 +++++++++++++++
> exec-obsolete.h | 50 ++++---
> exec.c | 34 +++--
> hmp-commands.hx | 34 +++++
> hmp.c | 90 ++++++++++++
> hmp.h | 3 +
> include/qemu/cache.h | 81 +++++++++++
> migration.c | 131 +++++++++++++++--
> migration.h | 30 +++-
> monitor.c | 7 +
> qapi-schema.json | 97 ++++++++++++-
> qemu-common.h | 19 +++
> qmp-commands.hx | 99 +++++++++++++
> savevm.c | 115 ++++++++++++++-
> sysemu.h | 3 +-
> trace-events | 5 +
> vmstate.h | 2 +-
> 23 files changed, 1449 insertions(+), 102 deletions(-)
> create mode 100644 cache.c
> create mode 100644 docs/xbzrle.txt
> create mode 100644 include/qemu/cache.h
>
>