Re: [RFC PATCH 0/3] generic hypercall support

Anthony Liguori
2009-05-08T14:54:21Z

Gregory Haskins wrote:
>> Greg,
>>
>> I think comparison is not entirely fair.
>>
>
> <snip>
>
> FYI: I've update the test/wiki to (hopefully) address your concerns.
>
> http://developer.novell.com/wiki/index.php/WhyHypercalls
>

And we're now getting close to the point where the difference is
virtually meaningless.

At .14us, in order to see 1% CPU overhead added from PIO vs HC, you need
71429 exits.

If you have this many exits, the shear cost of the base vmexit overhead
is going to result in about 15% CPU overhead. To put this another way,
if you're workload was entirely bound by vmexits (which is virtually
impossible), then when you were saturating your CPU at 100%, only 7% of
that is the cost of PIO exits vs. HC.

In real life workloads, if you're paying 15% overhead just to the cost
of exits (not including the cost of heavy weight or post-exit
processing), you're toast. I think it's going to be very difficult to
construct a real scenario where you'll have a measurable (i.e. > 1%)
performance overhead from using PIO vs. HC.

And in the absence of that, I don't see the justification for adding
additional infrastructure to Linux to support this.

The non-x86 architecture argument isn't valid because other
architectures either 1) don't use PCI at all (s390) and are already
using hypercalls 2) use PCI, but do not have a dedicated hypercall
instruction (PPC emb) or 3) have PIO (ia64).

Regards,

Anthony Liguori

> Regards,
> -Greg
>
>
>