qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hongyang Yang <yanghy@cn.fujitsu.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: kvm@vger.kernel.org, GuiJianfeng@cn.fujitsu.com,
	eddie.dong@intel.com, qemu-devel@nongnu.org,
	mrhines@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH 16/17] COLO ram cache: implement colo ram cache on slaver
Date: Fri, 12 Sep 2014 14:30:04 +0800	[thread overview]
Message-ID: <541292EC.3070907@cn.fujitsu.com> (raw)
In-Reply-To: <20140801151048.GH2430@work-vm>



在 08/01/2014 11:10 PM, Dr. David Alan Gilbert 写道:
> * Yang Hongyang (yanghy@cn.fujitsu.com) wrote:
>> The ram cache was initially the same as PVM's memory. At
>> checkpoint, we cache the dirty memory of PVM into ram cache
>> (so that ram cache always the same as PVM's memory at every
>> checkpoint), flush cached memory to SVM after we received
>> all PVM dirty memory(only needed to flush memory that was
>> both dirty on PVM and SVM since last checkpoint).
>
> (Typo: 'r' on the end of the title)
>
> I think I understand the need for the cache, to be able to restore pages
> that the SVM has modified that the PVM hadn't; however, if I understand
> the change here, (to host_from_stream_offset) the SVM will load the
> snapshot into the ram_cache rather than directly into host memory - why
> is this necessary?  If the SVMs CPU is stopped at this point couldn't
> it load snapshot pages directly into host memory, clearing pages in the SVMs
> bitmap, so that the only pages that then get copied in flush_cache are
> the pages that the SVM modified but the PVM *didn't* include in the snapshot?
> I can see that you would need to do it the way you've done it if the
> snapshot-load could fail (at the sametime the PVM failed) and thus the old SVM
> state would be the surviving state, but how could it fail at this point
> given the whole stream is in the colo-buffer?

I can see your confusion. Yes, you are right, we can do as what you said, but
at last, we still need to copy the dirty pages into ram cache as well (because
the ram cache is a snapshot and we need to keep this updated). So the question
is whether we load the dirty pages into snapshot first or into host memory
first. I think both methods can work and make no difference...

>
>
>> +static void ram_flush_cache(void);
>>   static int ram_load(QEMUFile *f, void *opaque, int version_id)
>>   {
>>       ram_addr_t addr;
>>       int flags, ret = 0;
>>       static uint64_t seq_iter;
>> +    bool need_flush = false;
>
> Probably better as 'ram_cache_needs_flush'
>
> Dave
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> .
>

-- 
Thanks,
Yang.

  reply	other threads:[~2014-09-12  6:30 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-23 14:25 [Qemu-devel] [RFC PATCH 00/17] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service Yang Hongyang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 01/17] configure: add CONFIG_COLO to switch COLO support Yang Hongyang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 02/17] COLO: introduce an api colo_supported() to indicate " Yang Hongyang
2014-07-23 15:47   ` Eric Blake
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 03/17] COLO migration: add a migration capability 'colo' Yang Hongyang
2014-07-23 14:41   ` Eric Blake
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 04/17] COLO info: use colo info to tell migration target colo is enabled Yang Hongyang
2014-08-01 14:43   ` Dr. David Alan Gilbert
2014-09-12  6:36     ` Hongyang Yang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 05/17] COLO save: integrate COLO checkpointed save into qemu migration Yang Hongyang
2014-08-01 14:46   ` Dr. David Alan Gilbert
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 06/17] COLO restore: integrate COLO checkpointed restore into qemu restore Yang Hongyang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 07/17] COLO buffer: implement colo buffer as well as QEMUFileOps based on it Yang Hongyang
2014-07-23 18:24   ` Eric Blake
2014-08-01 14:52   ` Dr. David Alan Gilbert
2014-09-17  1:43     ` Hongyang Yang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 08/17] COLO: disable qdev hotplug Yang Hongyang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 09/17] COLO ctl: implement API's that communicate with colo agent Yang Hongyang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 10/17] COLO ctl: introduce is_slave() and is_master() Yang Hongyang
2014-08-01 14:55   ` Dr. David Alan Gilbert
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 11/17] COLO ctl: implement colo checkpoint protocol Yang Hongyang
2014-08-01 15:03   ` Dr. David Alan Gilbert
2014-09-12  6:20     ` Hongyang Yang
2014-09-12 11:17       ` Dr. David Alan Gilbert
2014-09-12 11:40         ` Hongyang Yang
2014-09-12 11:57           ` Dr. David Alan Gilbert
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 12/17] COLO ctl: add a RunState RUN_STATE_COLO Yang Hongyang
2014-07-23 15:48   ` Eric Blake
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 13/17] COLO ctl: implement colo save Yang Hongyang
2014-08-01 15:07   ` Dr. David Alan Gilbert
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 14/17] COLO ctl: implement colo restore Yang Hongyang
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 15/17] COLO save: reuse migration bitmap under colo checkpoint Yang Hongyang
2014-08-01 15:09   ` Dr. David Alan Gilbert
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 16/17] COLO ram cache: implement colo ram cache on slaver Yang Hongyang
2014-08-01 15:10   ` Dr. David Alan Gilbert
2014-09-12  6:30     ` Hongyang Yang [this message]
2014-07-23 14:25 ` [Qemu-devel] [RFC PATCH 17/17] HACK: trigger checkpoint every 500ms Yang Hongyang
2014-07-23 15:44 ` [Qemu-devel] [RFC PATCH 00/17] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service Eric Blake
2014-07-24  2:24   ` Hongyang Yang
2014-08-01 16:02 ` Dr. David Alan Gilbert

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=541292EC.3070907@cn.fujitsu.com \
    --to=yanghy@cn.fujitsu.com \
    --cc=GuiJianfeng@cn.fujitsu.com \
    --cc=dgilbert@redhat.com \
    --cc=eddie.dong@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=mrhines@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /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).