From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Catterall Subject: Re: [RFC 0/4] HVM x86 enhancements to run Xen deprivileged mode operations Date: Wed, 12 Aug 2015 12:27:22 +0100 Message-ID: <55CB2D9A.7060001@citrix.com> References: <1438879519-564-1-git-send-email-Ben.Catterall@citrix.com> <55CB3303020000780009A0B8@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZPUCQ-0002Zc-4Z for xen-devel@lists.xenproject.org; Wed, 12 Aug 2015 11:28:02 +0000 In-Reply-To: <55CB3303020000780009A0B8@prv-mh.provo.novell.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: Jan Beulich Cc: keir@xen.org, ian.campbell@citrix.com, george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel List-Id: xen-devel@lists.xenproject.org On 12/08/15 10:50, Jan Beulich wrote: >>>> On 06.08.15 at 18:45, wrote: >> Performance testing >> ------------------- >> Performance testing indicates that the overhead for this deprivileged mode is >> approximately 25%. This overhead is the cost of moving into deprivileged mode >> and then fully back out of deprivileged mode. >> >> I performed 100000 writes to a single I/O port on an Intel 2.2GHz Xeon >> E5-2407 0 processor. This was done from a python script within the HVM guest >> using time.time() and running Debian Jessie. Each write was trapped to cause a >> vmexit and the time for each write was calculated. These experiments were >> repeated. Note that only the host and this HVM guest were running (both Debian >> Jessie) during the experiments. > > I'm not sure I/O port writes (the more without saying to which port) > are the best suited item for evaluating the overhead: Ideally you > would pick an operation that is comparably fast (I/O port accesses > generally aren't if the net effect is that the emulator accesses a > physical port). But it certainly serves as a first indication (not too > bad, but large enough that I wouldn't be convinced this is a good > idea). > > Jan > Thanks for this Jan: I overlooked this. Retested with the port (0x1000) i/o emulation operation replaced with a nop to get the pure overhead. With the operation takes 5.2e-6s and without takes 1.7e-6s. So the difference is 3.5e-6. That's about 308% overhead on a nop. So, I'm guessing that whether this is used or not will depend on the overhead and frequency of the operation it will be handling. Thanks, Ben