From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuKID-0002CS-4o for qemu-devel@nongnu.org; Thu, 26 Jul 2012 05:23:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuKI3-0006uE-Ba for qemu-devel@nongnu.org; Thu, 26 Jul 2012 05:23:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuKI3-0006tQ-0e for qemu-devel@nongnu.org; Thu, 26 Jul 2012 05:23:27 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6Q9NPrw005676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 26 Jul 2012 05:23:25 -0400 From: Juan Quintela In-Reply-To: <500FB956.9070306@redhat.com> (Avi Kivity's message of "Wed, 25 Jul 2012 12:16:06 +0300") References: <1343155012-26316-1-git-send-email-quintela@redhat.com> <1343155012-26316-11-git-send-email-quintela@redhat.com> <500FB956.9070306@redhat.com> Date: Thu, 26 Jul 2012 11:22:40 +0200 Message-ID: <87ehnyri5b.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 10/27] Separate migration bitmap Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Paolo Bonzini , Umesh Deshpande , qemu-devel@nongnu.org Avi Kivity wrote: > 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. I tried something like that myself (before your memory regions work). And got stuck on the same problem: - for migration, I always had a ramblock handy - for vga the same (well, I am not sure for the sparc ones, I think they were weird on that respect) - for TCG, there is none around that I can find. I guess it is there somewhere, but not in any obvious part. So, to fix TCG, we need a TCG guru, and probably change the access parters somehow :p Later, Juan.