[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.