[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A0AA6AE.5080709@novell.com>
Date: Wed, 13 May 2009 06:53:34 -0400
From: Gregory Haskins <ghaskins@...ell.com>
To: Anthony Liguori <anthony@...emonkey.ws>
CC: Gregory Haskins <gregory.haskins@...il.com>,
Avi Kivity <avi@...hat.com>,
Chris Wright <chrisw@...s-sol.org>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Hollis Blanchard <hollisb@...ibm.com>
Subject: Re: [RFC PATCH 0/3] generic hypercall support
Anthony Liguori wrote:
> Gregory Haskins wrote:
>>
>> So, yes, the delta from PIO to HC is 350ns. Yes, this is a ~1.4%
>> improvement. So what? Its still an improvement. If that improvement
>> were for free, would you object? And we all know that this change isn't
>> "free" because we have to change some code (+128/-0, to be exact). But
>> what is it specifically you are objecting to in the first place? Adding
>> hypercall support as an pv_ops primitive isn't exactly hard or complex,
>> or even very much code.
>>
>
> Where does 25us come from? The number you post below are 33us and 66us.
<snip>
The 25us is approximately the max from an in-kernel harness strapped
directly to the driver gathered informally during testing. The 33us is
from formally averaging multiple runs of a userspace socket app in
preparation for publishing. I consider the 25us the "target goal" since
there is obviously overhead that a socket application deals with that
theoretically a guest bypasses with the tap-device. Note that the
socket application itself often sees < 30us itself...this was just a
particularly "slow" set of runs that day.
Note that this is why I express the impact as "approximately" (e.g.
"~4%"). Sorry for the confusion.
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)
Powered by blists - more mailing lists