From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBBn-0004Lj-Ul for qemu-devel@nongnu.org; Fri, 22 Jun 2012 17:14:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiBBl-0005of-D0 for qemu-devel@nongnu.org; Fri, 22 Jun 2012 17:14:47 -0400 Received: from mout.web.de ([212.227.15.4]:55657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBBl-0005oE-1o for qemu-devel@nongnu.org; Fri, 22 Jun 2012 17:14:45 -0400 Message-ID: <4FE4E038.6000404@web.de> Date: Fri, 22 Jun 2012 23:14:32 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1340290158-11036-1-git-send-email-qemulist@gmail.com> <4FE33C61.9000509@siemens.com> <4FE44AE7.6050509@siemens.com> <4FE4D15C.2030708@codemonkey.ws> In-Reply-To: <4FE4D15C.2030708@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3BB35764A67D41B848E86E2" Subject: Re: [Qemu-devel] [RFC] use little granularity lock to substitue qemu_mutex_lock_iothread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-devel@nongnu.org" , liu ping fan , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC3BB35764A67D41B848E86E2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-22 22:11, Anthony Liguori wrote: > On 06/22/2012 05:37 AM, Jan Kiszka wrote: >> On 2012-06-22 12:24, liu ping fan wrote: >>> On Thu, Jun 21, 2012 at 11:23 PM, Jan Kiszka = >>> wrote: >>>> On 2012-06-21 16:49, Liu Ping Fan wrote: >>>>> Nowadays, we use >>>>> qemu_mutex_lock_iothread()/qemu_mutex_unlock_iothread() to >>>>> protect the race to access the emulated dev launched by vcpu >>>>> threads& iothread. >>>>> >>>>> But this lock is too big. We can break it down. >>>>> These patches separate the CPUArchState's protection from the other= >>>>> devices, so we >>>>> can have a per-cpu lock for each CPUArchState, not the big lock any= >>>>> longer. >>>> >>>> Anything that reduces lock dependencies is generally welcome. But ca= n >>>> you specify in more details what you gain, and under which condition= s? >>>> >>> In fact, there are several steps to break down the Qemu big lock. Thi= s >>> step just aims to shrink the code area protected by >>> qemu_mutex_lock_iothread()/qemu_mutex_unlock_iothread(). And I am >>> working on the following steps, which focus on breaking down the big >>> lock when calling handle_{io,mmio} >> >> Then let us discuss the strategy. This is important as it is unrealist= ic >> to break up the lock for all code paths. We really need to focus on >> goals that provide benefits for relevant use cases. >=20 > Stefan put together a proof of concept that implemented the data-plane > portion of virtio-blk in a separate thread. This is possible because o= f > I/O eventfd (we were able to select() on that fd in a separate thread).= >=20 > The performance difference between virtio-blk-pci and > virtio-blk-data-plane is staggering when dealing with a very large > storage system. >=20 > So we'd like to get the infrastructure in place where we can start > multithreading devices in QEMU to we can integrate this work. Can you name the primary bits? We really need to see the whole picture before adding new locks. They alone are not the solution. >=20 > The basic plan is introduce granular locking starting at the KVM > dispatch level until we can get to MemoryRegion dispatch. We'll then > have some way to indicate that a MemoryRegion's callbacks should be > invoked without holding the qemu global mutex. I don't disagree, but this end really looks like starting at the wrong edge. The changes are not isolated and surely not yet correct (run_on_cpu is broken for tcg e.g.). Then, none of this locking should be needed for in-kernel irqchips. All touched states are thread local or should be modifiable atomically - if not let's fix *that*, it's more beneficial. Actually, cpu_lock is counterproductive as it adds locking ops to a path where we will not need them later on in the normal configuration. User space irqchip is a slow path and perfectly fine to handle under BQL. So is VCPU control (pause/resume/run-on). It's better to focus on the fast path first. Jan --------------enigC3BB35764A67D41B848E86E2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/k4DoACgkQitSsb3rl5xSySwCdHAuwOzAz/fg66g/2Z8mm66CQ NSgAoOOPMEWnLs5aEQaeIvmJekzbi/SC =sJtx -----END PGP SIGNATURE----- --------------enigC3BB35764A67D41B848E86E2--