[Qemu-devel] Re: Role of qemu_fair_mutex

[Avi Kivity]

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