From: "FENG, Jiasheng" <nikofeng@connect.hku.hk>
To: qemu-devel@nongnu.org
Cc: Heming Cui <heming@cs.hku.hk>, Wang Cheng <wangch.will@gmail.com>,
"CHEN, XUSHENG" <chenxus@connect.hku.hk>,
"YE, Chen" <u3534845@connect.hku.hk>
Subject: [Qemu-devel] QEMU MicroCheckpointing Pause & Resume Latency
Date: Thu, 9 Mar 2017 16:49:26 +0800 [thread overview]
Message-ID: <CAGd9JPiCvSpZ6wGT-Fci+f7odP4t9SHUwSw3vqOMDVWdyJeR3w@mail.gmail.com> (raw)
Dear QEMU Development Team,
It is my honor to contact with you.
I am a postgraduate student from University of Hong Kong. Currently I am
working on a project related to QEMU MicroCheckpointing and I have
encountered a performance issue during checkpoint pause & resume.
Please kindly refer to migration/checkpoint.c file, in function
capture_checkpoint, I proceeded a test to see the time consumption between
vm_stop_force_state and vm_start. I found out that even if the system is
idle, there are still 12-20ms latency recorded ( mem=2G, vCPU=4 ).
Moreover, latency will be increased while more cpus equipped by my virtual
machine. I have done some research on that and I realized that it is
related to the Memory Barrier in KVM kernel. Each cpu will proceed a
smp_wmb() request during pause & resume and it takes about 3-5ms to finish
the request ( mem=2G, vCPU=4 ).
Therefore, I would like to ask 3 questions regarding on the above issue:
1. What is your consideration with calling smp_wmb() in checkpoint period;
2. Is it any other solution to minimize the latency to improve the
performance in checkpoint period;
3. Is smp_wmb() able to be safely disabled during the checkpoint period
Really appreciate your help with my problems and hope to receive your
feedback soon.
Thanks again for your contribution to QEMU and it is such a masterpiece.
Thanks and best regards,
Niko Jiasheng Feng
University of Hong Kong
--
*Niko Jiasheng *
*Feng **Computer Science(General Stream), Faculty of Engineering, The
University of Hong Kong*
Contact: (852)97908620
Address: Pokfulam Road, The University of Hong Kong
Email: nikofeng@hku.hk / niko_jiasheng@163.com
next reply other threads:[~2017-03-09 8:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 8:49 FENG, Jiasheng [this message]
2017-03-09 15:19 ` [Qemu-devel] QEMU MicroCheckpointing Pause & Resume Latency Dr. David Alan Gilbert
2017-03-09 16:37 ` FENG, Jiasheng
2017-03-09 17:06 ` Dr. David Alan Gilbert
2017-03-09 17:11 ` nikofeng
2017-03-09 17:15 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGd9JPiCvSpZ6wGT-Fci+f7odP4t9SHUwSw3vqOMDVWdyJeR3w@mail.gmail.com \
--to=nikofeng@connect.hku.hk \
--cc=chenxus@connect.hku.hk \
--cc=heming@cs.hku.hk \
--cc=qemu-devel@nongnu.org \
--cc=u3534845@connect.hku.hk \
--cc=wangch.will@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).