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 11:01 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

>     Having said that, libxl is not performance-optimised.  Indeed the

>     callback mechanism involves context switching, and IPC, between the
>     save/restore helper and libxl proper.  Probably not too much to be
>     doing every 20ms for a single domain, but if you have a lot of these
>     it's going to end up taking a lot of dom0 cpu etc.
>
> Yes and that is a problem. Xend+Remus avoided this by linking
> the libcheckpoint library that interfaced with both the python & libxc code.

Have you observed whether the performance is acceptable with your V3
patches ?

Frankly I don't know. At the moment, I am trying to make sure that the libxl-remus 

implementation is correct before I attempt to make it fast.

With/without these patches, there is a huge overhead per checkpoint. I cannot get to 

a 20ms checkpoint interval. Time to suspend/resume a domain is on the order of tens of 

milliseconds even if it was a PV domain with fast suspend support -- where it used to

take under 1ms to suspend, checkpoint and resume an idle PV domain on Xend+Remus.

This was one of the issues I raised a long time back. And this is currently the second 

element in my queue, the first being to get  the patches mainline, then slowly tighten up 

relevant code for performance.

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