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.