[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 2/3] remus: implement remus checkpoint in v2 save
On Wed, Jul 9, 2014 at 3:47 AM, Yang Hongyang <yanghy@xxxxxxxxxxxxxx> wrote: implement remus checkpoint in v2 save nit: last_iter I suggest adding a comment before this code block to explain what has happened so far above why we are jumping to the last_iter block skipping the rest of the stuff below.
I also suggest maintaining some stats structure somewhere (number of dirty pages, time when checkpoint was initiated, etc.). They could be simply debug prints that can be enabled on demand.
A better alternative would be to somehow pass this stats structure back to libxl, such that the user can enable/disable stats printing using the xl remus command for example.
   Â/* This juggling is required if logdirty is already on, e.g. VRAM tracking */ I hope the postsuspend callbacks are called somewhere?  @@ -570,44 +573,60 @@ static int save(struct xc_sr_context *ctx, uint16_t guest_type) I suggest using the ctx->firsttime bool var before this printf, so that when debug print is enabled under remus, the console is not
flooded with the same statement that makes no sense past the first iteration.  +      Ârc = send_domain_memory_live(ctx); A silly question: Shouldn't this check for 'suspended status' be before the call to send_domain_memory_live() [under remus]. I am assuming that the send_domain_memory_live() function is the one that sends the dirty page data
out on the wire. Â - Â Ârc = ctx->save.ops.end_of_stream(ctx); I suggest maintaining checkpoint numbers instead. Much more helpful. Probably even add a gettimeofday call to print out the time the new checkpoint is started. Once again, its useful
to be able to control this printout from libxl + Â Â Â Â Â Â} else { _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |