Re: [PATCH 0/6] migration/postcopy: enable compress during postcopy

[Dr. David Alan Gilbert]

* Wei Yang (address@hidden) wrote:
> On Thu, Nov 07, 2019 at 09:15:44AM +0000, Dr. David Alan Gilbert wrote:
> >* Wei Yang (address@hidden) wrote:
> >> On Wed, Nov 06, 2019 at 08:11:44PM +0000, Dr. David Alan Gilbert wrote:
> >> >* Wei Yang (address@hidden) wrote:
> >> >> This patch set tries enable compress during postcopy.
> >> >> 
> >> >> postcopy requires to place a whole host page, while migration thread 
> >> >> migrate
> >> >> memory in target page size. This makes postcopy need to collect all 
> >> >> target
> >> >> pages in one host page before placing via userfaultfd.
> >> >> 
> >> >> To enable compress during postcopy, there are two problems to solve:
> >> >> 
> >> >>     1. Random order for target page arrival
> >> >>     2. Target pages in one host page arrives without interrupt by target
> >> >>        page from other host page
> >> >> 
> >> >> The first one is handled by counting the number of target pages arrived
> >> >> instead of the last target page arrived.
> >> >> 
> >> >> The second one is handled by:
> >> >> 
> >> >>     1. Flush compress thread for each host page
> >> >>     2. Wait for decompress thread for before placing host page
> >> >> 
> >> >> With the combination of these two changes, compress is enabled during
> >> >> postcopy.
> >> >
> >> >What have you tested this with? 2MB huge pages I guess?
> >> >
> >> 
> >> I tried with this qemu option:
> >> 
> >>    -object 
> >> memory-backend-file,id=mem1,mem-path=/dev/hugepages/guest2,size=4G \
> >>    -device pc-dimm,id=dimm1,memdev=mem1
> >> 
> >> /dev/hugepages/guest2 is a file under hugetlbfs
> >> 
> >>    hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
> >
> >OK, yes that should be fine.
> >I suspect on Power/ARM where they have normal memory with 16/64k pages,
> >the cost of the flush will mean compression is more expensive in
> >postcopy mode; but still makes it possible.
> >
> 
> Not get your point clearly about more expensive. You mean more expensive on
> ARM/Power?

Yes;  you're doing a flush at the end of each host page;  on x86 without
hugepages you don't do anything, on arm/power you'll need to do a flush
at the end of each of their normal pages - so that's a bit more
expensive.

> If the solution looks good to you, I would prepare v2.

Yes; I think it is OK.

Dave

> >Dave
> >
> >> >Dave
> >> >
> >> >> Wei Yang (6):
> >> >>   migration/postcopy: reduce memset when it is zero page and
> >> >>     matches_target_page_size
> >> >>   migration/postcopy: wait for decompress thread in precopy
> >> >>   migration/postcopy: count target page number to decide the
> >> >>     place_needed
> >> >>   migration/postcopy: set all_zero to true on the first target page
> >> >>   migration/postcopy: enable random order target page arrival
> >> >>   migration/postcopy: enable compress during postcopy
> >> >> 
> >> >>  migration/migration.c | 11 --------
> >> >>  migration/ram.c       | 65 ++++++++++++++++++++++++++++++-------------
> >> >>  2 files changed, 45 insertions(+), 31 deletions(-)
> >> >> 
> >> >> -- 
> >> >> 2.17.1
> >> >> 
> >> >--
> >> >Dr. David Alan Gilbert / address@hidden / Manchester, UK
> >> 
> >> -- 
> >> Wei Yang
> >> Help you, Help me
> >--
> >Dr. David Alan Gilbert / address@hidden / Manchester, UK
> 
> -- 
> Wei Yang
> Help you, Help me
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK