Re: Role of qemu_fair_mutex

[Avi Kivity <avi@redhat.com>]

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