From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEyUw-0004RO-Nr for qemu-devel@nongnu.org; Fri, 21 Sep 2012 04:22:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEyUs-0003hI-Jy for qemu-devel@nongnu.org; Fri, 21 Sep 2012 04:22:06 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:55917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEyUs-0003hE-Ab for qemu-devel@nongnu.org; Fri, 21 Sep 2012 04:22:02 -0400 Date: Fri, 21 Sep 2012 04:21:58 -0400 (EDT) From: Paolo Bonzini Message-ID: <1532988625.3159868.1348215718197.JavaMail.root@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, Anthony Liguori > 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? Yes. > NOT want to open an argument, just a question, is there any reason > for the sequence devlock->timelock? Not any particular reason, just that it makes more sense. :) Backend subsystems (timers, network, I/O handlers, ...) typically will not call anything else. So it makes sense that their locks are held inside the device locks (and inside the big lock). Also note that while the timer subsystem could call the devices, it is perfectly plausible that the devices will do for example a qemu_mod_timer from a timer callback. Thus, in some sense the timer subsystem already has to expect modifications of its state during the callback. Releasing the lock during callbacks is "just" an extension of the current behavior. Of course some changes are needed to the invariants, such as the one Avi pointed out elsewhere in the thread, but devlock->timerlock is overall more natural than the opposite. Paolo