From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: [patch 00/13] RFC: split the global mutex
Date: Sun, 20 Apr 2008 21:00:42 -0300 [thread overview]
Message-ID: <20080421000041.GA30537@dmt> (raw)
In-Reply-To: <480B2624.9040805@qumranet.com>
On Sun, Apr 20, 2008 at 02:16:52PM +0300, Avi Kivity wrote:
> >The iperf numbers are pretty good. Performance of UP guests increase
> >slightly but SMP
> >is quite significant.
>
> I expect you're seeing contention induced by memcpy()s and inefficient
> emulation. With the dma api, I expect the benefit will drop.
You still have to memcpy() with the dma api. Even with vringfd the
kernel->user copy has to be performed under the global mutex protection,
difference being that several packets can be copied per-syscall instead
of only one.
> >Note that workloads with multiple busy devices (such as databases, web
> >servers) should
> >be the real winners.
> >
> >What is the feeling on this? Its not _that_ intrusive and can be easily
> >NOP'ed out for
> >QEMU.
> >
> >
>
> I think many parts are missing (or maybe, I missed them). You need to
> lock the qemu internals (there are many read-mostly qemu caches
> scattered around the code), lock against hotplug, etc.
Yes, there are some parts missing, such as the bh list and hotplug as
you mention.
> For pure cpu emulation, there is a ton of work to be done: protecting
> the translator as well as making the translated code smp safe.
I now believe there is a lot of work (which was not clear before).
Not particularly interested in getting real emulation to be
multithreaded.
Anyways, the lack of multithreading in qemu emulation should not be a
blocker for these patches to get in, since these are infrastructural
changes.
> I think that QemuDevice makes sense, and that we want this long term,
> but that we first need to improve efficiency (which reduces cpu
> utilization _and_ improves scalability) rather than look at scalability
> alone (which is much harder in addition to the drawback of not reducing
> cpu utilization).
Will complete the QEMUDevice+splitlock patchset, keep it uptodated, and
test it under a wider variety of workloads.
Thanks.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
next prev parent reply other threads:[~2008-04-21 0:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-17 20:10 [patch 00/13] RFC: split the global mutex Marcelo Tosatti
2008-04-17 20:10 ` [patch 01/13] QEMU: get rid of global cpu_single_env Marcelo Tosatti
2008-04-17 20:10 ` [patch 02/13] QEMU: introduce QEMUDevice Marcelo Tosatti
2008-04-17 20:10 ` [patch 03/13] QEMU: make esp.c build conditional to SPARC target Marcelo Tosatti
2008-04-17 20:10 ` [patch 04/13] QEMU: plug QEMUDevice pt1 / ioport awareness Marcelo Tosatti
2008-04-17 20:10 ` [patch 05/13] QEMU: add a mutex to protect IRQ chip data structures Marcelo Tosatti
2008-04-17 20:10 ` [patch 06/13] QEMU: plug QEMUDevice pt2 / iomem awareness Marcelo Tosatti
2008-04-17 20:10 ` [patch 07/13] QEMU: grab device lock for ioport/iomem processing Marcelo Tosatti
2008-04-17 20:10 ` [patch 08/13] QEMU: character device locking Marcelo Tosatti
2008-04-17 20:10 ` [patch 09/13] QEMU: network " Marcelo Tosatti
2008-04-17 20:10 ` [patch 10/13] QEMU: get rid of aiocb cache Marcelo Tosatti
2008-04-17 20:10 ` [patch 11/13] QEMU: block device locking Marcelo Tosatti
2008-04-17 20:10 ` [patch 12/13] QEMU: scsi-disk reentrancy fix Marcelo Tosatti
2008-04-17 20:10 ` [patch 13/13] QEMU/KVM: get rid of global lock Marcelo Tosatti
2008-04-20 11:16 ` [patch 00/13] RFC: split the global mutex Avi Kivity
2008-04-21 0:00 ` Marcelo Tosatti [this message]
2008-04-21 6:10 ` 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=20080421000041.GA30537@dmt \
--to=mtosatti@redhat.com \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
/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.