From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC PATCH v4 2/5] ramlist mutex Date: Tue, 23 Aug 2011 13:41:48 +0200 Message-ID: <4E5391FC.1060703@redhat.com> References: <8f99d56f3a48b6255cf70425bc435d8f231f5352.1313552764.git.udeshpan@redhat.com> <20110823091533.GA5207@amt.cnet> <20110823091726.GA5797@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Umesh Deshpande , kvm@vger.kernel.org, qemu-devel@nongnu.org, quintela@redhat.com To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:6568 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706Ab1HWLlz (ORCPT ); Tue, 23 Aug 2011 07:41:55 -0400 In-Reply-To: <20110823091726.GA5797@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 08/23/2011 11:17 AM, Marcelo Tosatti wrote: >>> > > typedef struct RAMList { >>> > > + QemuMutex mutex; >>> > > uint8_t *phys_dirty; >>> > > QLIST_HEAD(ram, RAMBlock) blocks; >>> > > QLIST_HEAD(, RAMBlock) blocks_mru; >> > >> > A comment on what the mutex protects would be good. Indeed, especially because Umesh wanted to use the ramlist+iothread combo as a rw-lock: iothread = read-lock for the I/O thread, ramlist = read-lock for the migration thread, together = exclusive (write) lock. But I think I talked him out of this. :) It's not a bad idea in general, it just sounds like overkill in this case. > And on the lock ordering. I think when only two locks are involved, we can always assume iothread is outer and the other is inner. Do you agree? Paolo