From: "Michael S. Tsirkin" <mst@redhat.com>
To: Christoffer Dall <cdall@cs.columbia.edu>
Cc: x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
kvm@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Sasha Levin <sasha.levin@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
virtualization@lists.linux-foundation.org,
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
Subject: Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
Date: Sun, 7 Apr 2013 10:41:13 +0300 [thread overview]
Message-ID: <20130407074113.GB10317@redhat.com> (raw)
In-Reply-To: <CAEDV+gKpCj1Sgn4TYw5ViYK-x4_c=-9nOpBwGfTBXRkJaN=gNg@mail.gmail.com>
On Thu, Apr 04, 2013 at 04:32:01PM -0700, Christoffer Dall wrote:
> [...]
>
> >> >> to give us some idea how much performance we would gain from each approach? Thoughput should be completely unaffected anyway, since virtio just coalesces kicks internally.
> >> >
> >> > Latency is dominated by the scheduling latency.
> >> > This means virtio-net is not the best benchmark.
> >>
> >> So what is a good benchmark?
> >
> > E.g. ping pong stress will do but need to look at CPU utilization,
> > that's what is affected, not latency.
> >
> >> Is there any difference in speed at all? I strongly doubt it. One of virtio's main points is to reduce the number of kicks.
> >
> > For this stage of the project I think microbenchmarks are more appropriate.
> > Doubling the price of exit is likely to be measureable. 30 cycles likely
> > not ...
> >
> I don't quite understand this point here. If we don't have anything
> real-world where we can measure a decent difference, then why are we
> doing this? I would agree with Alex that the three test scenarios
> proposed by him should be tried out before adding this complexity,
> measured in CPU utilization or latency as you wish.
Sure, plan to do real world benchmarks for PV MMIO versus PIO as well.
I don't see why I should bother implementing hypercalls given that the
kvm maintainer says they won't be merged.
> FWIW, ARM always uses MMIO and provides hardware decoding of all sane
> (not user register-writeback) instruction, but the hypercall vs. mmio
> looks like this:
>
> hvc: 4,917
> mmio_kernel: 6,248
So 20% difference? That's not far from what happens on my intel laptop:
vmcall 1519
outl_to_kernel 1745
10% difference here.
>
> But I doubt that an hvc wrapper around mmio decoding would take care
> of all this difference, because the mmio operation needs to do other
> work not realated to emulating the instruction in software, which
> you'd have to do for an hvc anyway (populate kvm_mmio structure etc.)
>
> -Christoffer
Instead of speculating, someone with relevant hardware
could just try this, but kvm unittest doesn't seem to have arm support
at the moment. Anyone working on this?
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Christoffer Dall <cdall@cs.columbia.edu>
Cc: Alexander Graf <agraf@suse.de>, Gleb Natapov <gleb@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>,
Alex Williamson <alex.williamson@redhat.com>,
Will Deacon <will.deacon@arm.com>,
Sasha Levin <sasha.levin@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH RFC] kvm: add PV MMIO EVENTFD
Date: Sun, 7 Apr 2013 10:41:13 +0300 [thread overview]
Message-ID: <20130407074113.GB10317@redhat.com> (raw)
In-Reply-To: <CAEDV+gKpCj1Sgn4TYw5ViYK-x4_c=-9nOpBwGfTBXRkJaN=gNg@mail.gmail.com>
On Thu, Apr 04, 2013 at 04:32:01PM -0700, Christoffer Dall wrote:
> [...]
>
> >> >> to give us some idea how much performance we would gain from each approach? Thoughput should be completely unaffected anyway, since virtio just coalesces kicks internally.
> >> >
> >> > Latency is dominated by the scheduling latency.
> >> > This means virtio-net is not the best benchmark.
> >>
> >> So what is a good benchmark?
> >
> > E.g. ping pong stress will do but need to look at CPU utilization,
> > that's what is affected, not latency.
> >
> >> Is there any difference in speed at all? I strongly doubt it. One of virtio's main points is to reduce the number of kicks.
> >
> > For this stage of the project I think microbenchmarks are more appropriate.
> > Doubling the price of exit is likely to be measureable. 30 cycles likely
> > not ...
> >
> I don't quite understand this point here. If we don't have anything
> real-world where we can measure a decent difference, then why are we
> doing this? I would agree with Alex that the three test scenarios
> proposed by him should be tried out before adding this complexity,
> measured in CPU utilization or latency as you wish.
Sure, plan to do real world benchmarks for PV MMIO versus PIO as well.
I don't see why I should bother implementing hypercalls given that the
kvm maintainer says they won't be merged.
> FWIW, ARM always uses MMIO and provides hardware decoding of all sane
> (not user register-writeback) instruction, but the hypercall vs. mmio
> looks like this:
>
> hvc: 4,917
> mmio_kernel: 6,248
So 20% difference? That's not far from what happens on my intel laptop:
vmcall 1519
outl_to_kernel 1745
10% difference here.
>
> But I doubt that an hvc wrapper around mmio decoding would take care
> of all this difference, because the mmio operation needs to do other
> work not realated to emulating the instruction in software, which
> you'd have to do for an hvc anyway (populate kvm_mmio structure etc.)
>
> -Christoffer
Instead of speculating, someone with relevant hardware
could just try this, but kvm unittest doesn't seem to have arm support
at the moment. Anyone working on this?
--
MST
next prev parent reply other threads:[~2013-04-07 7:41 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-04 10:50 [PATCH RFC] kvm: add PV MMIO EVENTFD Michael S. Tsirkin
2013-04-04 10:50 ` Michael S. Tsirkin
2013-04-04 11:57 ` Alexander Graf
2013-04-04 11:57 ` Alexander Graf
2013-04-04 11:04 ` Michael S. Tsirkin
2013-04-04 11:04 ` Michael S. Tsirkin
2013-04-04 12:09 ` Alexander Graf
2013-04-04 12:09 ` Alexander Graf
2013-04-04 11:21 ` Michael S. Tsirkin
2013-04-04 11:21 ` Michael S. Tsirkin
2013-04-04 12:19 ` Gleb Natapov
2013-04-04 12:19 ` Gleb Natapov
2013-04-04 12:22 ` Alexander Graf
2013-04-04 12:22 ` Alexander Graf
2013-04-04 12:08 ` Gleb Natapov
2013-04-04 12:08 ` Gleb Natapov
2013-04-04 12:22 ` Alexander Graf
2013-04-04 12:22 ` Alexander Graf
2013-04-04 12:34 ` Gleb Natapov
2013-04-04 12:34 ` Gleb Natapov
2013-04-04 12:39 ` Alexander Graf
2013-04-04 12:39 ` Alexander Graf
2013-04-04 12:58 ` Michael S. Tsirkin
2013-04-04 12:58 ` Michael S. Tsirkin
2013-04-04 14:02 ` Alexander Graf
2013-04-04 14:02 ` Alexander Graf
2013-04-04 13:40 ` Michael S. Tsirkin
2013-04-04 13:40 ` Michael S. Tsirkin
2013-04-04 12:32 ` Alexander Graf
2013-04-04 12:32 ` Alexander Graf
2013-04-04 12:38 ` Gleb Natapov
2013-04-04 12:38 ` Gleb Natapov
2013-04-04 12:39 ` Alexander Graf
2013-04-04 12:39 ` Alexander Graf
2013-04-04 12:45 ` Gleb Natapov
2013-04-04 12:45 ` Gleb Natapov
2013-04-04 12:49 ` Alexander Graf
2013-04-04 12:49 ` Alexander Graf
2013-04-04 12:56 ` Gleb Natapov
2013-04-04 12:56 ` Gleb Natapov
2013-04-04 13:06 ` Alexander Graf
2013-04-04 13:06 ` Alexander Graf
2013-04-04 13:14 ` Gleb Natapov
2013-04-04 13:14 ` Gleb Natapov
2013-04-04 14:26 ` Michael S. Tsirkin
2013-04-04 14:26 ` Michael S. Tsirkin
2013-04-07 9:30 ` Gleb Natapov
2013-04-07 9:30 ` Gleb Natapov
2013-04-07 8:43 ` Michael S. Tsirkin
2013-04-07 8:43 ` Michael S. Tsirkin
2013-04-04 13:33 ` Michael S. Tsirkin
2013-04-04 13:33 ` Michael S. Tsirkin
2013-04-04 15:36 ` Alexander Graf
2013-04-04 15:36 ` Alexander Graf
2013-04-04 15:36 ` Michael S. Tsirkin
2013-04-04 15:36 ` Michael S. Tsirkin
2013-04-04 16:39 ` Gleb Natapov
2013-04-04 16:39 ` Gleb Natapov
2013-04-04 23:32 ` Christoffer Dall
2013-04-07 7:41 ` Michael S. Tsirkin [this message]
2013-04-07 7:41 ` Michael S. Tsirkin
2013-04-07 21:25 ` Christoffer Dall
2013-04-04 23:32 ` Christoffer Dall
2013-04-04 16:33 ` Gleb Natapov
2013-04-04 16:33 ` Gleb Natapov
2013-04-04 13:12 ` Michael S. Tsirkin
2013-04-04 13:12 ` Michael S. Tsirkin
2013-04-04 13:06 ` Michael S. Tsirkin
2013-04-04 13:06 ` Michael S. Tsirkin
2013-04-04 13:03 ` Michael S. Tsirkin
2013-04-04 13:03 ` Michael S. Tsirkin
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=20130407074113.GB10317@redhat.com \
--to=mst@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cdall@cs.columbia.edu \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sasha.levin@oracle.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
--cc=xiaoguangrong@linux.vnet.ibm.com \
--cc=yoshikawa_takuya_b1@lab.ntt.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.