[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC v2 0/4] HVM x86 deprivileged mode operations



>>> On 04.09.15 at 11:16, <ian.campbell@xxxxxxxxxx> wrote:
> On Fri, 2015-09-04 at 02:33 -0600, Jan Beulich wrote:
>> > 
>> > > > On 03.09.15 at 18:01, <Ben.Catterall@xxxxxxxxxx> wrote:
>> > I performed 100000 writes to a single I/O port on an Intel 2.2GHz Xeon
>> > E5-2407 0 processor and an AMD Opteron 2376. 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. 
>> > The 
>> > port
>> > operation is bypassed so that no portio is actually performed. Thus, 
>> > the
>> > differences in the measurements below can be taken as the pure 
>> > overhead. 
>> > These
>> > experiments were repeated. Note that only the host and this HVM guest 
>> > were
>> > running (both Debian Jessie) during the experiments.
>> > 
>> > Intel Intel 2.2GHz Xeon E5-2407 0 processor:
>> > --------------------------------------------
>> > 1.55e-06 seconds was the average time for performing the write without 
>> > the
>> >          deprivileged code running.
>> > 
>> > 5.75e-06 seconds was the average time for performing the write with the
>> >          deprivileged code running.
>> > 
>> > So approximately 351% overhead
>> > 
>> > AMD Opteron 2376:
>> > -----------------
>> > 1.74e-06 seconds was the average time for performing the write without 
>> > the
>> >          deprivileged code running.
>> > 3.10e-06 seconds was the average time for performing the write with an 
>> > entry 
>> > and
>> >          exit from deprvileged mode.
>> > 
>> > So approximately 178% overhead.
>> 
>> Just like said for v1: Determining a percentage of overhead is
>> pretty meaningless when the actual operation (the I/O port
>> access) can take significantly varying amount of time depending
>> on which I/O port is being accessed. In particular, considering
>> the built in devices emulation of which you want to move out,
>> the majority shouldn't actually be doing any accesses to ports
>> or MMIO, but just act on RAM. Which hence may take quite a
>> bit less than the roughly 1.5us you use as the base line, in turn
>> likely resulting in quite a bit higher relative overhead.
> 
> Ben says "no port io is actually performed", so I think the 1.5us is purely
> the overhead of emulating an I/O access as a NOP.

Oh, I see - I didn't pay close enough attention and judged only
from "I performed 100000 writes to a single I/O port ...". I'm
sorry.

Otoh - 1.5us seems quite a long time if there's no actual port
access...

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.