From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stxha-0004is-C3 for qemu-devel@nongnu.org; Wed, 25 Jul 2012 05:16:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StxhT-0006E2-In for qemu-devel@nongnu.org; Wed, 25 Jul 2012 05:16:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StxhT-0006Db-Ar for qemu-devel@nongnu.org; Wed, 25 Jul 2012 05:16:11 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6P9GAWa028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jul 2012 05:16:10 -0400 Message-ID: <500FB956.9070306@redhat.com> Date: Wed, 25 Jul 2012 12:16:06 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1343155012-26316-1-git-send-email-quintela@redhat.com> <1343155012-26316-11-git-send-email-quintela@redhat.com> In-Reply-To: <1343155012-26316-11-git-send-email-quintela@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 10/27] Separate migration bitmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Paolo Bonzini , Umesh Deshpande , qemu-devel@nongnu.org On 07/24/2012 09:36 PM, Juan Quintela wrote: > This patch creates a migration bitmap, which is periodically kept in > sync with the qemu bitmap. A separate copy of the dirty bitmap for the > migration limits the amount of concurrent access to the qemu bitmap > from iothread and migration thread (which requires taking the big > lock). > > We use the qemu bitmap type. We have to "undo" the dirty_pages > counting optimization on the general dirty bitmap and do the counting > optimization with the migration local bitmap. I had different plans for this (and a stale and possibly smelly patchset moving in that direction): - move the dirty bytemap from a single global instance to per-memory-region instances (in the MemoryRegion structure) - convert it from a bytemap to either a per-client bitmap (client = VGA/CODE/MIGRATION) or a variable bit-length bitfieldmap - allocate the bitmaps or strangely named thingie above on demand, so ordinarily you have nothing allocated and the framebuffer has a bitmap, when you start migration you allocate a bitmap for memory and a twobitmap for the framebuffer - protect the whole thing using rcu The patchset is stalled, mostly because it's very difficult to disentangle the tcg stuff. I don't think we should introduce a dependency here, just something to keep in mind. -- error compiling committee.c: too many arguments to function