From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] tools/libxc: Avoid hypercalls for cacheflush on x86 Date: Tue, 4 Mar 2014 11:22:08 +0000 Message-ID: <5315B760.3080408@citrix.com> References: <1393857478-14993-1-git-send-email-andrew.cooper3@citrix.com> <21268.44109.423294.653166@mariner.uk.xensource.com> <1393895670.10902.7.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1393895670.10902.7.camel@hastur.hellion.org.uk> 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 Campbell Cc: Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org On 04/03/14 01:14, Ian Campbell wrote: > On Mon, 2014-03-03 at 16:22 +0000, Ian Jackson wrote: >> Andrew Cooper writes ("[PATCH] tools/libxc: Avoid hypercalls for cacheflush on x86"): >>> XEN_DOMCTL_cacheflush hypercalls are -ENOSYS on x86. As domain >>> creation/migration is already very hypercall-heavy, avoid making extra >>> redundant hypercalls >> Surely this should be done by moving the relevant code to an >> arm-specific file, not by #ifdeffery. > I think it is very debatable that sort-circuiting a single ENOSYS > hypercall in the tools is even worth it at all. "very hypercall heavy" > doesn't cut it as a rationale IMHO. Unless an actual demonstrable > improvement is seen, perhaps over a larger series removing a large > number of so called redundant calls, it's just an additional source of > confusion (due to gating at multiple levels) as far as I'm concerned. > > Ian. > For booting a single guest, noone will notice. Booting 10 or more at a time however is very different. XenServer, along with all other virtualisation platforms live in a world where "Net time to boot $N guests" (where N is measured in hundreds) is an important quantity, and needless overhead from things like this cause dom0 needless load that it would rather do without. I should say that I have not done any performance metrics on this - as noted in the patch I stumbled upon it with valgrind. ~Andrew