Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock

[liu ping fan]

On Thu, Sep 20, 2012 at 5:07 PM, Avi Kivity <address@hidden> wrote:
> On 09/20/2012 10:51 AM, liu ping fan wrote:
>> On Wed, Sep 19, 2012 at 5:23 PM, Avi Kivity <address@hidden> wrote:
>>> On 09/19/2012 12:19 PM, liu ping fan wrote:
>>>> On Wed, Sep 19, 2012 at 5:14 PM, Paolo Bonzini <address@hidden> wrote:
>>>>> Il 19/09/2012 11:11, liu ping fan ha scritto:
>>>>>>> > Why not? devA will drop its local lock, devX will retake the big lock
>>>>>>> > recursively, devB will take its local lock.  In the end, we have 
>>>>>>> > biglock
>>>>>>> > -> devB.
>>>>>>> >
>>>>>> But when adopting local lock, we assume take local lock, then biglock.
>>>>>
>>>>> No, because the local lock will be dropped before taking the biglock.
>>>>> The order must always be coarse->fine.
>>>>>
>>>> But if we takes coarse firstly, then the mmio-dispatcher will still
>>>> contend for the big lock against each other.
>>>
>>> Can you detail the sequence?
>>>
>> LOCK(local lock)
>> .......................
>> LOCK(big lock)
>> Access timer/block/network subsystem
>> UNLOCK(big lock)
>> .....................
>> UNLOCK(local lock)
>
> This is an invalid sequence.  Either the subsystem has to be fine-grain
> locked, or the lock order has to be reversed.
>
Oh!  And from this thread, my understanding of the reason for the rule
of lock sequence: coarse->fine is that biglock means higher
possibility of conflict, so we try it first, then try the fine-lock.
In this way, we have a smaller window for holding fine-lock which
means the other thread can get this lock more smoothly.  Right?
NOT want to open an argument, just a question, is there any reason for
the sequence
devlock->timelock?

Regards,
pingfan
> Before we finish subsystem conversion, an mmio dispatcher may look like:
>
> dev_write(...)
> {
>     lock(s->lock)
>     switch (addr) {
>         case REGA:
>             ...
>         case REGB:
>             ...
>         case REGC:
>             unlock(s->lock)
>             lock(big lock)
>             lock(s->lock)
>             qemu_mod_timer()
>             unlock(bit lock)
>             break;
>         ...
>     }
>     unlock(s->lock)
> }
>
>
>
> --
> error compiling committee.c: too many arguments to function