From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtIx9-0000f9-3B for qemu-devel@nongnu.org; Mon, 02 Nov 2015 12:31:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtIx5-0000Z8-KB for qemu-devel@nongnu.org; Mon, 02 Nov 2015 12:31:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtIx5-0000Z0-Ea for qemu-devel@nongnu.org; Mon, 02 Nov 2015 12:31:27 -0500 Date: Mon, 2 Nov 2015 17:31:21 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20151102173120.GA22239@work-vm> References: <1443515898-3594-1-git-send-email-dgilbert@redhat.com> <1443515898-3594-33-git-send-email-dgilbert@redhat.com> <87lhawa2sj.fsf@neno.neno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhawa2sj.fsf@neno.neno> Subject: Re: [Qemu-devel] [PATCH v8 32/54] Postcopy: Maintain sentmap and calculate discard List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: aarcange@redhat.com, liang.z.li@intel.com, qemu-devel@nongnu.org, luis@cs.umu.se, bharata@linux.vnet.ibm.com, amit.shah@redhat.com, pbonzini@redhat.com * Juan Quintela (quintela@redhat.com) wrote: > > +/* > > + * Transmit the set of pages to be discarded after precopy to the target > > + * these are pages that: > > + * a) Have been previously transmitted but are now dirty again > > + * b) Pages that have never been transmitted, this ensures that > > + * any pages on the destination that have been mapped by background > > + * tasks get discarded (transparent huge pages is the specific concern) > > + * Hopefully this is pretty sparse > > + */ > > +int ram_postcopy_send_discard_bitmap(MigrationState *ms) > > +{ > > + int ret; > > + > > + rcu_read_lock(); > > + > > + /* This should be our last sync, the src is now paused */ > > + migration_bitmap_sync(); > > + > > + /* > > + * Update the sentmap to be sentmap = ~sentmap | dirty > > + */ > > + bitmap_complement(ms->sentmap, ms->sentmap, > > + last_ram_offset() >> TARGET_PAGE_BITS); > > + > > + bitmap_or(ms->sentmap, ms->sentmap, migration_bitmap, > > + last_ram_offset() >> TARGET_PAGE_BITS); > > This bitmaps are really big, I don't know how long would take to do this > operations here, but I think that we can avoid (at least) the > bitmap_complement. We can change the bitmap name to notsentbitmap, init > it to one and clear it each time that we sent a page, no? Done, it's now 'unsentmap' - although I suspect the complement step is probably one of the simpler steps in the process, I'm not sure it's a vast saving. > We can also do the bitmap_or() at migration_sync_bitmap() time, at that > point, we shouldn't be on the critical path? Given that we're doing the bitmap_sync immediately before the OR, I don't understand that line; are you talking about a modified migration_bitmap_sync? Dave > > Later, Juan. -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK