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

Anthony Liguori
2009-05-10T18:38:34Z

Gregory Haskins wrote:
> Anthony Liguori wrote:
>
>
>> I'm surprised so much effort is going into this, is there any
>> indication that this is even close to a bottleneck in any circumstance?
>>
>
> Yes. Each 1us of overhead is a 4% regression in something as trivial as
> a 25us UDP/ICMP rtt "ping".m
>

It wasn't 1us, it was 350ns or something around there (i.e ~1%).

> for request-response, this is generally for *every* packet since you
> cannot exploit buffering/deferring.
>
> Can you back up your claim that PPC has no difference in performance
> with an MMIO exit and a "hypercall" (yes, I understand PPC has no "VT"
> like instructions, but clearly there are ways to cause a trap, so
> presumably we can measure the difference between a PF exit and something
> more explicit).
>

First, the PPC that KVM supports performs very poorly relatively
speaking because it receives no hardware assistance this is not the
right place to focus wrt optimizations.

And because there's no hardware assistance, there simply isn't a
hypercall instruction. Are PFs the fastest type of exits? Probably not
but I honestly have no idea. I'm sure Hollis does though.

Page faults are going to have tremendously different performance
characteristics on PPC too because it's a software managed TLB. There's
no page table lookup like there is on x86.

As a more general observation, we need numbers to justify an
optimization, not to justify not including an optimization.

In other words, the burden is on you to present a scenario where this
optimization would result in a measurable improvement in a real world
work load.

Regards,

Anthony Liguori
> We need numbers before we can really decide to abandon this
> optimization. If PPC mmio has no penalty over hypercall, I am not sure
> the 350ns on x86 is worth this effort (especially if I can shrink this
> with some RCU fixes). Otherwise, the margin is quite a bit larger.
>
> -Greg
>
>
>
>