From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46060) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbtba-0004yA-C8 for qemu-devel@nongnu.org; Tue, 15 Sep 2015 13:01:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbtbU-0004z2-B9 for qemu-devel@nongnu.org; Tue, 15 Sep 2015 13:01:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbtbU-0004yy-3K for qemu-devel@nongnu.org; Tue, 15 Sep 2015 13:01:12 -0400 Date: Tue, 15 Sep 2015 18:01:05 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150915170105.GA31256@work-vm> References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-26-git-send-email-dgilbert@redhat.com> <87mvz0jn2t.fsf@neno.neno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mvz0jn2t.fsf@neno.neno> Subject: Re: [Qemu-devel] [PATCH v7 25/42] 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, yamahata@private.email.ne.jp, liang.z.li@intel.com, qemu-devel@nongnu.org, luis@cs.umu.se, amit.shah@redhat.com, pbonzini@redhat.com, david@gibson.dropbear.id.au * Juan Quintela (quintela@redhat.com) wrote: > "Dr. David Alan Gilbert (git)" wrote: > > From: "Dr. David Alan Gilbert" > > > > Where postcopy is preceeded by a period of precopy, the destination will > > have received pages that may have been dirtied on the source after the > > page was sent. The destination must throw these pages away before > > starting it's CPUs. > > > > Maintain a 'sentmap' of pages that have already been sent. > > Calculate list of sent & dirty pages > > Provide helpers on the destination side to discard these. > > > > Signed-off-by: Dr. David Alan Gilbert > > Not a patch without a suggestion O:-) > > > --- > > include/migration/migration.h | 12 +++ > > include/migration/postcopy-ram.h | 35 +++++++ > > include/qemu/typedefs.h | 1 + > > migration/migration.c | 1 + > > migration/postcopy-ram.c | 108 +++++++++++++++++++++ > > migration/ram.c | 203 ++++++++++++++++++++++++++++++++++++++- > > migration/savevm.c | 2 - > > trace-events | 5 + > > 8 files changed, 363 insertions(+), 4 deletions(-) > > > > diff --git a/include/migration/migration.h b/include/migration/migration.h > > index 2a22381..4c6cf95 100644 > > --- a/include/migration/migration.h > > +++ b/include/migration/migration.h > > @@ -114,6 +114,13 @@ struct MigrationState > > > > /* Flag set once the migration has been asked to enter postcopy */ > > bool start_postcopy; > > + > > + /* bitmap of pages that have been sent at least once > > + * only maintained and used in postcopy at the moment > > + * where it's used to send the dirtymap at the start > > + * of the postcopy phase > > + */ > > + unsigned long *sentmap; > > }; > > We can use this sentmap for zero page optimization. If page is on > sentmap, we need to sent a zero page, otherwise, just sent sentmap at > the end of migration and clean everything not there? Just as a compact way of sending zero pages? I'm not sure it would help. > > +/* > > + * Discard the contents of memory start..end inclusive. > > + * We can assume that if we've been called postcopy_ram_hosttest returned true > > + */ > > +int postcopy_ram_discard_range(MigrationIncomingState *mis, uint8_t *start, > > + uint8_t *end) > > +{ > > + trace_postcopy_ram_discard_range(start, end); > > + if (madvise(start, (end-start)+1, MADV_DONTNEED)) { > > Can we s/end/lenght/ and adjust everywhere? Done - partially; everything that works in bytes is now start & length, everything that works in indexes into the RAM bitmap is still start/end, since generally that's what they're working with already. > Not here, but putting a comment explaining where magic 12 cames from on > definition of constant? Done. > I think that the sentbitmap bits could we used without the rest. Possibly, I can kind of see it's useful - but I'm not convinced what else for yet. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK