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

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

 



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



--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux