From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Liu Ping Fan <pingfank@linux.vnet.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH v2 0/7] kvm: Get coalesced MMIO flushing out of the hot-path
Date: Thu, 28 Jun 2012 19:09:50 +0300 [thread overview]
Message-ID: <4FEC81CE.3010802@redhat.com> (raw)
In-Reply-To: <cover.1340814444.git.jan.kiszka@siemens.com>
On 06/27/2012 07:27 PM, Jan Kiszka wrote:
> Changes in v2:
> - added memory_region_clear_flush_coalesced
> - call memory_region_clear_flush_coalesced from
> memory_region_clear_coalescing
> - wrap all region manipulations via memory_region_transaction_begin/
> commit internally
> - flush coalesced MMIO only on memory_region_transaction_begin
>
> Original description:
>
> We currently flush the coalesced MMIO buffer on every vmexit to
> userspace. KVM only provides a single buffer per VM, so a central lock
> is required to read from it. This is a contention point given a large
> enough VCPU set. Moreover, we need to hold the BQL while replaying the
> queued requests, probably for a long time until there is more fine
> grained locking available. Good reasons to overcome the unconditional
> flush.
>
> The series achieves this by flushing only on selected memory region
> accesses, either generically via the memory access dispatcher or
> directly on certain VGA PIO accesses that are not yet fully converted.
> Another reason to flush are remappings or other relevant region state
> changes.
Looks good; please see minor comment on patch 2.
--
error compiling committee.c: too many arguments to function
prev parent reply other threads:[~2012-06-28 16:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 16:27 [PATCH v2 0/7] kvm: Get coalesced MMIO flushing out of the hot-path Jan Kiszka
2012-06-27 16:27 ` [PATCH v2 1/7] i82378: Remove bogus MMIO coalescing Jan Kiszka
2012-06-27 16:27 ` [PATCH v2 2/7] memory: Flush coalesced MMIO on selected region access Jan Kiszka
2012-06-28 16:07 ` Avi Kivity
2012-06-29 16:37 ` [PATCH v3 " Jan Kiszka
2012-07-02 9:07 ` Avi Kivity
2012-07-02 9:07 ` [Qemu-devel] " Avi Kivity
2012-07-02 9:07 ` Avi Kivity
2012-07-02 9:07 ` [Qemu-devel] " Avi Kivity
2012-07-10 10:41 ` Jan Kiszka
2012-07-10 10:41 ` [Qemu-devel] " Jan Kiszka
2012-08-17 10:55 ` Jan Kiszka
2012-08-17 10:55 ` [Qemu-devel] " Jan Kiszka
2012-08-19 9:46 ` Avi Kivity
2012-08-19 9:46 ` [Qemu-devel] " Avi Kivity
2012-06-27 16:27 ` [PATCH v2 3/7] memory: Use transaction_begin/commit also for single-step operations Jan Kiszka
2012-06-27 16:27 ` [PATCH v2 4/7] memory: Fold memory_region_update_topology into memory_region_transaction_commit Jan Kiszka
2012-06-27 16:27 ` [PATCH v2 5/7] memory: Flush coalesced MMIO on mapping and state changes Jan Kiszka
2012-06-27 16:27 ` [PATCH v2 6/7] VGA: Flush coalesced MMIO on related MMIO/PIO accesses Jan Kiszka
2012-06-27 16:27 ` [PATCH v2 7/7] kvm: Stop flushing coalesced MMIO on vmexit Jan Kiszka
2012-06-28 16:09 ` Avi Kivity [this message]
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=4FEC81CE.3010802@redhat.com \
--to=avi@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pingfank@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.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 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.