On Wed, Sep 19, 2012 at 5:23 PM, Avi Kivity <a...@redhat.com> wrote: > 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? > LOCK(local lock) ....................... LOCK(big lock) Access timer/block/network subsystem UNLOCK(big lock) ..................... UNLOCK(local lock) >> >>> 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. > Sorry, donot catching your meaning. Does not "coarse->fine" mean LOCK(coarse)-->LOCK(fine); .. UNLOCK(fine)-->UNLOCK(coarse) ?
> Valid: > lock(coarse) > lock(fine) > But it is conflict with " localLock(fine) --> bigLock(coarse)" which is taken when mmio dispatch. Regards, pingfan > Valid: > lock(find) > > Valid: > lock(coarse) > > Invalid: > lock(fine) > lock(coarse) > > > -- > error compiling committee.c: too many arguments to function