From: Hollis Blanchard <hollisb@us.ibm.com>
To: Gregory Haskins <gregory.haskins@gmail.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
Gregory Haskins <ghaskins@novell.com>,
Avi Kivity <avi@redhat.com>, Chris Wright <chrisw@sous-sol.org>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] generic hypercall support
Date: Mon, 11 May 2009 11:35:12 -0500 [thread overview]
Message-ID: <1242059712.29194.12.camel@slate.austin.ibm.com> (raw)
In-Reply-To: <4A0824C2.4000109@gmail.com>
On Mon, 2009-05-11 at 09:14 -0400, Gregory Haskins wrote:
>
> >> 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
>
> So wouldn't that be making the case that it could use as much help as
> possible?
I think he's referencing Ahmdal's Law here. While I'd agree, this is
relevant only for the current KVM PowerPC implementations. I think it
would be short-sighted to design an IO architecture around that.
> > this is not the right place to focus wrt optimizations.
>
> Odd choice of words. I am advocating the opposite (broad solution to
> many arches and many platforms (i.e. hypervisors)) and therefore I am
> not "focused" on it (or really any one arch) at all per se. I am
> _worried_ however, that we could be overlooking PPC (as an example) if
> we ignore the disparity between MMIO and HC since other higher
> performance options are not available like PIO. The goal on this
> particular thread is to come up with an IO interface that works
> reasonably well across as many hypervisors as possible. MMIO/PIO do
> not appear to fit that bill (at least not without tunneling them over
> HCs)
I haven't been following this conversation at all. With that in mind...
AFAICS, a hypercall is clearly the higher-performing option, since you
don't need the additional memory load (which could even cause a page
fault in some circumstances) and instruction decode. That said, I'm
willing to agree that this overhead is probably negligible compared to
the IOp itself... Ahmdal's Law again.
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2009-05-11 16:35 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-05 13:24 Gregory Haskins
2009-05-05 13:24 ` [RFC PATCH 1/3] add " Gregory Haskins
2009-05-05 17:03 ` Hollis Blanchard
2009-05-06 13:52 ` Anthony Liguori
2009-05-06 15:16 ` Gregory Haskins
2009-05-06 16:52 ` Arnd Bergmann
2009-05-05 13:24 ` [RFC PATCH 2/3] x86: " Gregory Haskins
2009-05-05 13:24 ` [RFC PATCH 3/3] kvm: add pv_cpu_ops.hypercall support to the guest Gregory Haskins
2009-05-05 13:36 ` [RFC PATCH 0/3] generic hypercall support Avi Kivity
2009-05-05 13:40 ` Gregory Haskins
2009-05-05 14:00 ` Avi Kivity
2009-05-05 14:14 ` Gregory Haskins
2009-05-05 14:21 ` Gregory Haskins
2009-05-05 15:02 ` Avi Kivity
2009-05-05 23:17 ` Chris Wright
2009-05-06 3:51 ` Gregory Haskins
2009-05-06 7:22 ` Chris Wright
2009-05-06 13:17 ` Gregory Haskins
2009-05-06 16:07 ` Chris Wright
2009-05-07 17:03 ` Gregory Haskins
2009-05-07 18:05 ` Avi Kivity
2009-05-07 18:08 ` Gregory Haskins
2009-05-07 18:12 ` Avi Kivity
2009-05-07 18:16 ` Gregory Haskins
2009-05-07 18:24 ` Avi Kivity
2009-05-07 18:37 ` Gregory Haskins
2009-05-07 19:00 ` Avi Kivity
2009-05-07 19:05 ` Gregory Haskins
2009-05-07 19:43 ` Avi Kivity
2009-05-07 20:07 ` Gregory Haskins
2009-05-07 20:15 ` Avi Kivity
2009-05-07 20:26 ` Gregory Haskins
2009-05-08 8:35 ` Avi Kivity
2009-05-08 11:29 ` Gregory Haskins
2009-05-07 19:07 ` Chris Wright
2009-05-07 19:12 ` Gregory Haskins
2009-05-07 19:21 ` Chris Wright
2009-05-07 19:26 ` Avi Kivity
2009-05-07 19:44 ` Avi Kivity
2009-05-07 19:29 ` Gregory Haskins
2009-05-07 20:25 ` Chris Wright
2009-05-07 20:34 ` Gregory Haskins
2009-05-07 20:54 ` Arnd Bergmann
2009-05-07 21:13 ` Gregory Haskins
2009-05-07 21:57 ` Chris Wright
2009-05-07 22:11 ` Arnd Bergmann
2009-05-08 22:33 ` Benjamin Herrenschmidt
2009-05-11 13:01 ` Arnd Bergmann
2009-05-11 13:04 ` Gregory Haskins
2009-05-07 20:00 ` Arnd Bergmann
2009-05-07 20:31 ` Gregory Haskins
2009-05-07 20:42 ` Arnd Bergmann
2009-05-07 20:47 ` Arnd Bergmann
2009-05-07 20:50 ` Chris Wright
2009-05-07 23:35 ` Marcelo Tosatti
2009-05-07 23:43 ` Marcelo Tosatti
2009-05-08 3:17 ` Gregory Haskins
2009-05-08 7:55 ` Avi Kivity
[not found] ` <20090508103253.GC3011@amt.cnet>
2009-05-08 11:37 ` Avi Kivity
2009-05-08 3:13 ` Gregory Haskins
2009-05-08 7:59 ` Avi Kivity
2009-05-08 11:09 ` Gregory Haskins
[not found] ` <20090508104228.GD3011@amt.cnet>
2009-05-08 12:43 ` Gregory Haskins
2009-05-08 15:33 ` Marcelo Tosatti
2009-05-08 19:02 ` Avi Kivity
2009-05-08 16:48 ` Paul E. McKenney
2009-05-08 19:55 ` Gregory Haskins
2009-05-08 14:15 ` Gregory Haskins
2009-05-08 14:53 ` Anthony Liguori
2009-05-08 18:50 ` Avi Kivity
2009-05-08 19:02 ` Anthony Liguori
2009-05-08 19:06 ` Avi Kivity
2009-05-11 16:37 ` Jeremy Fitzhardinge
2009-05-07 12:29 ` Avi Kivity
2009-05-08 14:59 ` Anthony Liguori
2009-05-09 12:01 ` Gregory Haskins
2009-05-10 18:38 ` Anthony Liguori
2009-05-11 13:14 ` Gregory Haskins
2009-05-11 16:35 ` Hollis Blanchard [this message]
2009-05-11 17:06 ` Avi Kivity
2009-05-11 17:29 ` Gregory Haskins
2009-05-11 17:53 ` Avi Kivity
2009-05-11 17:51 ` Anthony Liguori
2009-05-11 18:02 ` Avi Kivity
2009-05-11 18:18 ` Anthony Liguori
2009-05-11 17:31 ` Anthony Liguori
2009-05-13 10:53 ` Gregory Haskins
2009-05-13 14:45 ` Gregory Haskins
2009-05-11 16:44 ` Hollis Blanchard
2009-05-11 17:54 ` Anthony Liguori
2009-05-11 19:24 ` PowerPC page faults Hollis Blanchard
2009-05-11 22:17 ` Anthony Liguori
2009-05-12 5:46 ` Liu Yu-B13201
2009-05-12 14:50 ` Hollis Blanchard
2009-05-06 13:56 ` [RFC PATCH 0/3] generic hypercall support Anthony Liguori
2009-05-06 16:03 ` Gregory Haskins
2009-05-08 8:17 ` Avi Kivity
2009-05-08 15:20 ` Gregory Haskins
2009-05-08 17:00 ` Avi Kivity
2009-05-08 18:55 ` Gregory Haskins
2009-05-08 19:05 ` Anthony Liguori
2009-05-08 19:12 ` Avi Kivity
2009-05-08 19:59 ` Gregory Haskins
2009-05-10 9:59 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1242059712.29194.12.camel@slate.austin.ibm.com \
--to=hollisb@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=ghaskins@novell.com \
--cc=gregory.haskins@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®