From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: Role of qemu_fair_mutex Date: Tue, 4 Jan 2011 19:39:20 -0200 Message-ID: <20110104213920.GA7379@amt.cnet> References: <4D219AF5.2030204@web.de> <4D219E6D.8060902@redhat.com> <4D232BF6.6050102@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Jan Kiszka , qemu-devel , kvm To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22989 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750871Ab1ADW3x (ORCPT ); Tue, 4 Jan 2011 17:29:53 -0500 Content-Disposition: inline In-Reply-To: <4D232BF6.6050102@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jan 04, 2011 at 08:17:26AM -0600, Anthony Liguori wrote: > On 01/03/2011 04:01 AM, Avi Kivity wrote: > >On 01/03/2011 11:46 AM, Jan Kiszka wrote: > >>Hi, > >> > >>at least in kvm mode, the qemu_fair_mutex seems to have lost its > >>function of balancing qemu_global_mutex access between the io-thread and > >>vcpus. It's now only taken by the latter, isn't it? > >> > >>This and the fact that qemu-kvm does not use this kind of lock made me > >>wonder what its role is and if it is still relevant in practice. I'd > >>like to unify the execution models of qemu-kvm and qemu, and this lock > >>is the most obvious difference (there are surely more subtle ones as > >>well...). > >> > > > >IIRC it was used for tcg, which has a problem that kvm doesn't > >have: a tcg vcpu needs to hold qemu_mutex when it runs, which > >means there will always be contention on qemu_mutex. In the > >absence of fairness, the tcg thread could dominate qemu_mutex and > >starve the iothread. > > No, it's actually the opposite IIRC. > > TCG relies on the following behavior. A guest VCPU runs until 1) > it encounters a HLT instruction 2) an event occurs that forces the > TCG execution to break. > > (2) really means that the TCG thread receives a signal. Usually, > this is the periodic timer signal. > > When the TCG thread, it needs to let the IO thread run for at least > one iteration. Coordinating the execution of the IO thread such > that it's guaranteed to run at least once and then having it drop > the qemu mutex long enough for the TCG thread to acquire it is the > purpose of the qemu_fair_mutex. Its the vcpu threads that starve the IO thread. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48318 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaFO6-0000OS-JC for qemu-devel@nongnu.org; Tue, 04 Jan 2011 17:29:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PaFO5-0003oW-AA for qemu-devel@nongnu.org; Tue, 04 Jan 2011 17:29:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PaFO5-0003oM-3C for qemu-devel@nongnu.org; Tue, 04 Jan 2011 17:29:53 -0500 Date: Tue, 4 Jan 2011 19:39:20 -0200 From: Marcelo Tosatti Message-ID: <20110104213920.GA7379@amt.cnet> References: <4D219AF5.2030204@web.de> <4D219E6D.8060902@redhat.com> <4D232BF6.6050102@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D232BF6.6050102@codemonkey.ws> Subject: [Qemu-devel] Re: Role of qemu_fair_mutex List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , Avi Kivity , kvm , qemu-devel On Tue, Jan 04, 2011 at 08:17:26AM -0600, Anthony Liguori wrote: > On 01/03/2011 04:01 AM, Avi Kivity wrote: > >On 01/03/2011 11:46 AM, Jan Kiszka wrote: > >>Hi, > >> > >>at least in kvm mode, the qemu_fair_mutex seems to have lost its > >>function of balancing qemu_global_mutex access between the io-thread and > >>vcpus. It's now only taken by the latter, isn't it? > >> > >>This and the fact that qemu-kvm does not use this kind of lock made me > >>wonder what its role is and if it is still relevant in practice. I'd > >>like to unify the execution models of qemu-kvm and qemu, and this lock > >>is the most obvious difference (there are surely more subtle ones as > >>well...). > >> > > > >IIRC it was used for tcg, which has a problem that kvm doesn't > >have: a tcg vcpu needs to hold qemu_mutex when it runs, which > >means there will always be contention on qemu_mutex. In the > >absence of fairness, the tcg thread could dominate qemu_mutex and > >starve the iothread. > > No, it's actually the opposite IIRC. > > TCG relies on the following behavior. A guest VCPU runs until 1) > it encounters a HLT instruction 2) an event occurs that forces the > TCG execution to break. > > (2) really means that the TCG thread receives a signal. Usually, > this is the periodic timer signal. > > When the TCG thread, it needs to let the IO thread run for at least > one iteration. Coordinating the execution of the IO thread such > that it's guaranteed to run at least once and then having it drop > the qemu mutex long enough for the TCG thread to acquire it is the > purpose of the qemu_fair_mutex. Its the vcpu threads that starve the IO thread.