qemu-devel
[Top][All Lists]
Advanced

[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: Tue, 14 Feb 2017 11:26:00 +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.
> 
> 
> >> +static int ram_multifd_page(QEMUFile *f, PageSearchStatus *pss,
> >> +                            bool last_stage, uint64_t *bytes_transferred)
> >> +{
> >> +    int pages;
> >> +    uint8_t *p;
> >> +    RAMBlock *block = pss->block;
> >> +    ram_addr_t offset = pss->offset;
> >> +
> >> +    p = block->host + offset;
> >> +
> >> +    if (block == last_sent_block) {
> >> +        offset |= RAM_SAVE_FLAG_CONTINUE;
> >> +    }
> >> +    pages = save_zero_page(f, block, offset, p, bytes_transferred);
> >> +    if (pages == -1) {
> >> +        *bytes_transferred +=
> >> +            save_page_header(f, block, offset | 
> >> RAM_SAVE_FLAG_MULTIFD_PAGE);
> >> +        qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
> >> +        *bytes_transferred += TARGET_PAGE_SIZE;
> >> +        pages = 1;
> >> +        acct_info.norm_pages++;
> >> +        acct_info.multifd_pages++;
> >> +    }
> >> +
> >> +    return pages;
> >> +}
> >> +
> >>  static int do_compress_ram_page(QEMUFile *f, RAMBlock *block,
> >>                                  ram_addr_t offset)
> >>  {
> >> @@ -1427,6 +1461,8 @@ static int ram_save_target_page(MigrationState *ms, 
> >> QEMUFile *f,
> >>              res = ram_save_compressed_page(f, pss,
> >>                                             last_stage,
> >>                                             bytes_transferred);
> >> +        } else if (migrate_use_multifd()) {
> >> +            res = ram_multifd_page(f, pss, last_stage, bytes_transferred);
> >
> > I'm curious whether it's best to pick the destination fd at this level or 
> > one level
> > higher; for example would it be good to keep all the components of a
> > host page or huge
> > page together on the same fd? If so then it would be best to pick the fd
> > at ram_save_host_page level.
> 
> my plan here would be to change the migration code to be able to call
> with a bigger sizes, not page by page, and then the problem is solved by
> itself?

Yes it might be, but you may have to be careful to keep all your FDs busy;
for example, imagine that we're using huge pages, and you try and stuff
an entire hugepage down one FD, for 2MB hugepages that's about half of the
write buffer (tcp-wmem?) so there's a fair chance it'll block.  But thereagain
I think it's probably the right thing to do as long as you can get
different pages down different FDs.

Dave

> Later, Juan.
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]