All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "FENG, Jiasheng" <nikofeng@connect.hku.hk>
Cc: qemu-devel@nongnu.org, Wang Cheng <wangch.will@gmail.com>,
	"YE, Chen" <u3534845@connect.hku.hk>,
	"CHEN, XUSHENG" <chenxus@connect.hku.hk>,
	Heming Cui <heming@cs.hku.hk>
Subject: Re: [Qemu-devel] QEMU MicroCheckpointing Pause & Resume Latency
Date: Thu, 9 Mar 2017 15:19:23 +0000	[thread overview]
Message-ID: <20170309151923.GG2480@work-vm> (raw)
In-Reply-To: <CAGd9JPiCvSpZ6wGT-Fci+f7odP4t9SHUwSw3vqOMDVWdyJeR3w@mail.gmail.com>

* FENG, Jiasheng (nikofeng@connect.hku.hk) wrote:
> 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.

The microcheckpointing code hasn't been maintained for a long time;
most of the current checkpointing work is based on the COLO work which is
still under development.

> 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

Well you'd have to understand where it's used; but for example, when taking
a checkpoint you'd want to be sure that the checkpoint data contained
a consistent copy of the last write data from all of the vCPUs; so I think
a wmb would be needed to make sure it's consistent.

I'm surprised that the smp_wmb is such a big chunk of your total checkpoint
time, and that it's quite so long.  
Are the vCPUs idle or are they busy - does it make difference?

Dave

> 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.

Dave

> 
> 
> 
> 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
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2017-03-09 15:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09  8:49 [Qemu-devel] QEMU MicroCheckpointing Pause & Resume Latency FENG, Jiasheng
2017-03-09 15:19 ` Dr. David Alan Gilbert [this message]
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=20170309151923.GG2480@work-vm \
    --to=dgilbert@redhat.com \
    --cc=chenxus@connect.hku.hk \
    --cc=heming@cs.hku.hk \
    --cc=nikofeng@connect.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.