On 09/19/2012 12:19 PM, liu ping fan wrote: > On Wed, Sep 19, 2012 at 5:14 PM, Paolo Bonzini <pbonz...@redhat.com> 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? > >> I don't know if the front-end (device) lock should come before or after >> the back-end (e.g. netdev) lock in the hierarchy, but that's another story. >> > I think fine->coarse may be the rule, since for some code path, it is > not necessary to take coarse lock. coarse->fine doesn't mean you have to take the coarse lock. Valid: lock(coarse) lock(fine) Valid: lock(find) Valid: lock(coarse) Invalid: lock(fine) lock(coarse) -- error compiling committee.c: too many arguments to function
