Re: [PATCH RFC 07/20] migration: defer precopy policy to libxl

From: Ian Jackson <ian.jackson@eu.citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	czylin@uwaterloo.ca, Joshua Otto <jtotto@uwaterloo.ca>,
	imhy.yang@gmail.com, xen-devel@lists.xenproject.org,
	hjarmstr@uwaterloo.ca
Subject: Re: [PATCH RFC 07/20] migration: defer precopy policy to libxl
Date: Tue, 18 Apr 2017 18:56:59 +0100	[thread overview]
Message-ID: <22774.21355.57924.570392@mariner.uk.xensource.com> (raw)
In-Reply-To: <20170412151626.5zlyl2d7zdwnjj7m@citrix.com>

Wei Liu writes ("Re: [PATCH RFC 07/20] migration: defer precopy policy to libxl"):
> On Thu, Mar 30, 2017 at 01:19:41AM -0400, Joshua Otto wrote:
> > Is the memcpy() really significant here?  If this were a tight
> > loop, sure, but every invocation of the policy callback implies
> > both a 4MB network transfer _and_ a synchronous RPC.
> 
> Ian, How can Joshua pass a pointer across RPC boundary to avoid excessive
> copying?

You can't pass a pointer across the IPC boundary.  The two bits of
code run in different processes, with different address spaces.

Also, this precopy stats struct is tiny: two unsigned and a long.
Josuha is entirely right to ask whether the overhead is significant.
I think it isn't.

If the performance of the proposed arrangements is inadequate, the
whole design needs reconsideration - the synchronous callback is more
of a concer, as Joshua suggests.  But I assume it's not, or Joshua
would have noticed !

Thanks,
Ian.

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