From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhHP0-00032B-36 for qemu-devel@nongnu.org; Thu, 14 Jul 2011 04:36:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QhHOx-00015E-Ui for qemu-devel@nongnu.org; Thu, 14 Jul 2011 04:36:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QhHOx-00014t-AO for qemu-devel@nongnu.org; Thu, 14 Jul 2011 04:36:07 -0400 Message-ID: <4E1EAA72.1060103@redhat.com> Date: Thu, 14 Jul 2011 11:36:02 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1447945249.1317755.1310627692984.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> In-Reply-To: <1447945249.1317755.1310627692984.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] New thread for the VM migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Umesh Deshpande Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/14/2011 10:14 AM, Umesh Deshpande wrote: > Following patch is implemented to deal with the VCPU and iothread starvation during the migration of a guest. Currently iothread is responsible for performing the migration. It holds the qemu_mutex during the migration and doesn't allow VCPU to enter the qemu mode and delays its return to the guest. The guest migration, executed as an iohandler also delays the execution of other iohandlers. In the following patch, the migration has been moved to a separate thread to reduce the qemu_mutex contention and iohandler starvation. > > > @@ -260,10 +260,15 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, void *opaque) > return 0; > } > > + if (stage != 3) > + qemu_mutex_lock_iothread(); Please read CODING_STYLE, especially the bit about braces. Does this mean that the following code is sometimes executed without qemu_mutex? I don't think any of it is thread safe. Even just reading memory is not thread safe. You either have to copy it into a buffer under lock, or convert the memory API to RCU. -- error compiling committee.c: too many arguments to function