[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 10/17] migration: create ram_multifd_page
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 10/17] migration: create ram_multifd_page |
Date: |
Thu, 2 Feb 2017 11:04:13 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
* Juan Quintela (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> wrote:
> > * Juan Quintela (address@hidden) wrote:
> >> The function still don't use multifd, but we have simplified
> >> ram_save_page, xbzrle and RDMA stuff is gone. We have added a new
> >> counter and a new flag for this type of pages.
> >>
> >> Signed-off-by: Juan Quintela <address@hidden>
>
> >> --- a/migration/ram.c
> >> +++ b/migration/ram.c
> >> @@ -61,6 +61,7 @@ static uint64_t bitmap_sync_count;
> >> #define RAM_SAVE_FLAG_XBZRLE 0x40
> >> /* 0x80 is reserved in migration.h start with 0x100 next */
> >> #define RAM_SAVE_FLAG_COMPRESS_PAGE 0x100
> >> +#define RAM_SAVE_FLAG_MULTIFD_PAGE 0x200
> >
> > I think a similar reminder from the last iteration of this patch;
> > I think we're out of bits here - I'm not sure if 0x200 is even
> > available.
>
> In previous iteration, I used *two* bits. As per your recomendation, I
> "reused" and old one for doing the synchronization.
Hmm OK, but that's still the last free bit; given TARGET_PAGE_BITS 10
on 3 targets, we can't use 0x400.
I guess the next user of a new bit will need to use RAM_SAVE_FLAG_FULL
which has never really been used and that will have to be some
magic that caused another block of bits to be read.
Dave
>
> Later, Juan.
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [PATCH 10/17] migration: create ram_multifd_page,
Dr. David Alan Gilbert <=