From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shriram Rajagopalan Subject: Re: [PATCH 4 of 5 V3] tools/libxl: Control network buffering in remus callbacks [and 1 more messages] Date: Mon, 4 Nov 2013 11:23:40 -0600 Message-ID: References: <21107.62159.140005.466786@mariner.uk.xensource.com> <21111.36679.369553.735409@mariner.uk.xensource.com> <1383579138.8826.95.camel@kazak.uk.xensource.com> <21111.50707.178276.553159@mariner.uk.xensource.com> <21111.53967.622234.211632@mariner.uk.xensource.com> Reply-To: rshriram@cs.ubc.ca Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1726619812428976531==" Return-path: In-Reply-To: <21111.53967.622234.211632@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Andrew Cooper , Stefano Stabellini , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============1726619812428976531== Content-Type: multipart/alternative; boundary=bcaec517cdfcc3766804ea5d2fe8 --bcaec517cdfcc3766804ea5d2fe8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 4, 2013 at 11:01 AM, Ian Jackson 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. --bcaec517cdfcc3766804ea5d2fe8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 4, 2013 at 11:01 AM, Ian Jackson <Ian= .Jackson@eu.citrix.com> wrote:
=
> =A0 =A0 Having said that, libxl is not = performance-optimised. =A0Indeed the
> =A0 =A0 callback mechanism involves context switching, and IPC, betwee= n the
> =A0 =A0 save/restore helper and libxl proper. =A0Probably not too much= to be
> =A0 =A0 doing every 20ms for a single domain, but if you have a lot of= these
> =A0 =A0 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 & l= ibxc code.

Have you observed whether the performance is acceptable with your V3<= br> patches ?


Frankly I don't know. A= t the moment, I am trying to make sure that the libxl-remus=A0
im= plementation is correct before I attempt to make it fast.

With/without these patches, there is a huge overhead per checkpo= int. I cannot get to=A0
a 20ms checkpoint interval. Time to suspe= nd/resume a domain is on the order of tens of=A0
milliseconds eve= n 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=A0
element in my= queue, the first being to get =A0the patches mainline, then slowly tighten= up=A0
relevant code for performance.

--bcaec517cdfcc3766804ea5d2fe8-- --===============1726619812428976531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1726619812428976531==--