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.
