Re: [Xen-devel] [PATCH 4 of 5 V3] tools/libxl: Control network buffering in remus callbacks [and 1 more messages]

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Mon, Nov 4, 2013 at 6:12 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

Shriram Rajagopalan writes ("Re: [PATCH 4 of 5 V3] tools/libxl: Control network buffering in remus callbacks"):
> Nanosleep was more of my personal preference,

I don't think that's a good enough reason for the churn, but as I say
this really ought to be replaced with use of a timeout event.

Fair enough. My question is what is the overhead of setting up, firing and tearing down

a timeout event using the event gen framework, if I wish to checkpoint the VM, say every 20ms ?

If you happen to have the numbers off the top of your head, it would help. Or if you are sure that

the system can easily handle this rate of events with very little overhead (<0.2ms per event)

> As far as using the event loop timers, I couldn't find anything
> suitable in libxl_event.h/c that I could use instead of
> usleep/nanosleep.  Specifically, they were all asynchronous, while
> the caller of these functions is libxc's xc_domain_save infinite
> loop (synchronous).

No, you need to make it an asynchronous call.

The libxl save helper machinery arranges to run xc_domain_save in a
subprocess so that the main program can continue asynchronously.

It's true that the suspend checkpoint is currently synchronous.  It
needs to be made synchronous by telling the stub generator
(libxl_save_msgs_gen.pl) to generate an asynchronous binding, like it
does for switch_qemu_logdirty.

Perhaps it would be helpful if I provided a pre-patch to make that
change for you.

Yes, that would be pretty helpful. Thanks!

  

shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel