Re: Role of qemu_fair_mutex

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/04/2011 04:55 PM, Anthony Liguori wrote:


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.

That doesn't compute - the iothread doesn't hog the global lock (it sleeps most of the time, and drops the lock while sleeping), so the iothread cannot starve out tcg.

The fact that the iothread drops the global lock during sleep is a detail that shouldn't affect correctness. The IO thread is absolutely allowed to run for arbitrary periods of time without dropping the qemu mutex.

No, it's not, since it will stop vcpus in their tracks. Whenever we hold qemu_mutex for unbounded time, that's a bug. I think the only place is live migration and perhaps tcg?


On the other hand, tcg does hog the global lock, so it needs to be made to give it up so the iothread can run, for example my completion example.

It's very easy to ask TCG to give up the qemu_mutex by using cpu_interrupt(). It will drop the qemu_mutex and it will not attempt to acquire it again until you restart the VCPU.

Maybe that's the solution:

def acquire_global_mutex():
   if not tcg_thread:
      cpu_interrupt()
   global_mutex.aquire()

release_global_mutex():
    global_mutex.release()
    if not tcg_thread:
       cpu_resume()

though it's racy, two non-tcg threads can cause an early resume.


I think the abstraction we need here is a priority lock, with higher priority given to the iothread. A lock() operation that takes precedence would atomically signal the current owner to drop the lock.

The I/O thread can reliably acquire the lock whenever it needs to.

If you drop all of the qemu_fair_mutex stuff and leave the qemu_mutex getting dropped around select, TCG will generally work reliably. But this is not race free.

What would be the impact of a race here?

Just dropping a lock does not result in reliable hand off.

Why do we want a handoff in the first place?

I don't think we do. I think we want the iothread to run in preference to tcg, since tcg is a lock hog under guest control, while the iothread is not a lock hog (excepting live migration).


I think a generational counter could work and a condition could work.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux