diff mbox

[v9,00/56] Postcopy implementation

Message ID 20151109110302.GB2513@work-vm
State New
Headers show

Commit Message

Dr. David Alan Gilbert Nov. 9, 2015, 11:03 a.m. UTC
* Bharata B Rao (bharata@linux.vnet.ibm.com) wrote:
> On Mon, Nov 09, 2015 at 09:08:33AM +0000, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bharata@linux.vnet.ibm.com) wrote:
> > > On Fri, Nov 06, 2015 at 03:48:11PM +0000, Dr. David Alan Gilbert wrote:
> > > > * Bharata B Rao (bharata@linux.vnet.ibm.com) wrote:

<snip>

> > Can you :
> >    1) show me the command line you're using
> 
> ./ppc64-softmmu/qemu-system-ppc64 --enable-kvm --nographic -vga none -machine pseries -m 64G,slots=32,maxmem=128G -smp 16 -device virtio-blk-pci,drive=rootdisk -drive file=/home/bharata/F20-snap1,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -trace events=my-trace-events

Thanks; looks sensible.

> >    2) Show me /proc/pid/smaps for the destination qemu
> 
> Attached.

> 3fef23ff0000-3fff23ff0000 rw-p 00000000 00:00 0 
> Size:           67108864 kB
> Rss:            67108864 kB
> Pss:            67108864 kB
> Shared_Clean:          0 kB
> Shared_Dirty:          0 kB
> Private_Clean:         0 kB
> Private_Dirty:  67108864 kB
> Referenced:     67108864 kB
> Anonymous:      67108864 kB
> AnonHugePages:     32768 kB
> Swap:                  0 kB
> SwapPss:               0 kB
> KernelPageSize:       64 kB
> MMUPageSize:          64 kB
> Locked:                0 kB
> VmFlags: rd wr mr mw me dc ac hg mg 

OK, all dirty - that's not happy.

> >    3) Turn on the trace     postcopy_place_page_zero
> >       the theory is that most of your pages should end up as zero pages
> >       and not be allocated.
> 
> No hits for postcopy_place_page_zero either in source or destination QEMU.

OK, that's why it's all dirty then - it should be placing most pages
as zero pages; I checked and that is triggering on x86.

Oh, I think I see it; the following is untested, I'll grab a machine to
try it on but it will take a little while:


Thanks for spotting this!

Dave

> 
> Regards,
> Bharata.

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Comments

Bharata B Rao Nov. 9, 2015, 12:39 p.m. UTC | #1
On Mon, Nov 09, 2015 at 11:03:02AM +0000, Dr. David Alan Gilbert wrote:
> <snip>
> 
> Oh, I think I see it; the following is untested, I'll grab a machine to
> try it on but it will take a little while:
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 62cf42b..e6db965 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2273,6 +2274,7 @@ static int ram_load_postcopy(QEMUFile *f)
>      /* Temporary page that is later 'placed' */
>      void *postcopy_host_page = postcopy_get_tmp_page(mis);
>      void *last_host = NULL;
> +    bool all_zero = false;
> 
>      while (!ret && !(flags & RAM_SAVE_FLAG_EOS)) {
>          ram_addr_t addr;
> @@ -2280,7 +2282,6 @@ static int ram_load_postcopy(QEMUFile *f)
>          void *page_buffer = NULL;
>          void *place_source = NULL;
>          uint8_t ch;
> -        bool all_zero = false;
> 
>          addr = qemu_get_be64(f);
>          flags = addr & ~TARGET_PAGE_MASK;

So with the above fix on top of the previous one you sent, I am able to
do back and forth postcopy migration of pseries guest within the
same host while switching to postcopy mode immediately after starting
the migration.

And btw I can see lots of hits to postcopy_place_page_zero now!

Regards,
Bharata.
Dr. David Alan Gilbert Nov. 9, 2015, 12:52 p.m. UTC | #2
* Bharata B Rao (bharata@linux.vnet.ibm.com) wrote:
> On Mon, Nov 09, 2015 at 11:03:02AM +0000, Dr. David Alan Gilbert wrote:
> > <snip>
> > 
> > Oh, I think I see it; the following is untested, I'll grab a machine to
> > try it on but it will take a little while:
> > 
> > diff --git a/migration/ram.c b/migration/ram.c
> > index 62cf42b..e6db965 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -2273,6 +2274,7 @@ static int ram_load_postcopy(QEMUFile *f)
> >      /* Temporary page that is later 'placed' */
> >      void *postcopy_host_page = postcopy_get_tmp_page(mis);
> >      void *last_host = NULL;
> > +    bool all_zero = false;
> > 
> >      while (!ret && !(flags & RAM_SAVE_FLAG_EOS)) {
> >          ram_addr_t addr;
> > @@ -2280,7 +2282,6 @@ static int ram_load_postcopy(QEMUFile *f)
> >          void *page_buffer = NULL;
> >          void *place_source = NULL;
> >          uint8_t ch;
> > -        bool all_zero = false;
> > 
> >          addr = qemu_get_be64(f);
> >          flags = addr & ~TARGET_PAGE_MASK;
> 
> So with the above fix on top of the previous one you sent, I am able to
> do back and forth postcopy migration of pseries guest within the
> same host while switching to postcopy mode immediately after starting
> the migration.
> 
> And btw I can see lots of hits to postcopy_place_page_zero now!

Excellent!  Thanks for finding that; that misplaced line has been
in there for about a year :-)

Dave

> 
> Regards,
> Bharata.
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
diff mbox

Patch

diff --git a/migration/ram.c b/migration/ram.c
index 62cf42b..e6db965 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2273,6 +2274,7 @@  static int ram_load_postcopy(QEMUFile *f)
     /* Temporary page that is later 'placed' */
     void *postcopy_host_page = postcopy_get_tmp_page(mis);
     void *last_host = NULL;
+    bool all_zero = false;
 
     while (!ret && !(flags & RAM_SAVE_FLAG_EOS)) {
         ram_addr_t addr;
@@ -2280,7 +2282,6 @@  static int ram_load_postcopy(QEMUFile *f)
         void *page_buffer = NULL;
         void *place_source = NULL;
         uint8_t ch;
-        bool all_zero = false;
 
         addr = qemu_get_be64(f);
         flags = addr & ~TARGET_PAGE_MASK;