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

[Shriram Rajagopalan <rshriram@cs.ubc.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 1377 bytes --]

On Mon, Nov 4, 2013 at 11:01 AM, Ian Jackson <Ian.Jackson@eu.citrix.com>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.

[-- Attachment #1.2: Type: text/html, Size: 2051 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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